You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(scripts): close the three conditional import leaks, shrinking KNOWN_IMPORT_UNSAFE 5 -> 2 (#11951)
* fix(scripts): guard qa-rollup's --self-test dispatch against importers
`qa-rollup.mjs` exports bindings and tested `--self-test` BEFORE the entry
guard, so the branch read the IMPORTER's argv: any tool that imported this
module for its exports while carrying `--self-test` in its own argv ran
qa-rollup's entire self-test inside itself.
The leak is invisible to the two signals a caller usually has. The self-test
does not exit on success, so the importer survives with status 0 and finishes
its own work; the only trace is 82 bytes of foreign output on the importer's
stdout. Measured with a probe that prints a sentinel AFTER the dynamic import
and counts bytes that are not the sentinel:
before LEAK scripts/qa/qa-rollup.mjs argv --self-test FOREIGN-BYTES=82
after CLEAN scripts/qa/qa-rollup.mjs argv --self-test
Guard first, mode second. CLI behaviour is unchanged — `--self-test` output is
byte-identical before and after (85 bytes, `cmp` clean), because the guard is
true for every direct invocation.
`check:entry-guard` names the file STALE once it is inert, so its
KNOWN_IMPORT_UNSAFE line goes in this same commit: the ledger shrinks 5 -> 4
and the gate's own count moves to `108 of them inert on import (4
known-unsafe)`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015ahemw8RcTgqtxrj15PEZx
* fix(scripts): move objectui-range's --help out of module top level
`objectui-range.mjs` exports bindings and answered `-h`/`--help` from a bare
top-level `if`, so the test read the IMPORTER's argv. An importer carrying
either flag got this file's 4666-byte `//` header written to its stdout and
then `process.exit(0)`.
That is the worst-reading shape in this class: the importer's process ends
mid-import with a SUCCESS status, so a caller holding only `result.status`
cannot tell it from a clean import. Measured with a probe that prints a
sentinel AFTER the dynamic import — the sentinel is what makes the two
distinguishable, exit status alone is not:
before LEAK argv --help NO-SENTINEL(status=0) FOREIGN-BYTES=4666
before LEAK argv -h NO-SENTINEL(status=0) FOREIGN-BYTES=4666
after CLEAN argv --help
after CLEAN argv -h
The help text is unchanged, and deliberately so: it is read back out of this
file's own `//` lines, so a comment added at column 0 would rewrite it. The
new rationale is a `/** */` block for that reason and the column-0 `//` count
is still 79. All four CLI surfaces are byte-identical before and after —
`--help` 4693 bytes, `-h` 4693, no-args 93 bytes on stderr with status 1, and
`--self-test` 1578 bytes, every one `cmp`-clean on both streams.
`check:entry-guard` names the file STALE once it is inert, so its
KNOWN_IMPORT_UNSAFE line goes in this same commit: the ledger shrinks 4 -> 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015ahemw8RcTgqtxrj15PEZx
* fix(scripts): arm ts-parse's census report on first parse, not on import
`ts-parse.mjs` registered its `OS_TOOLING_PARSE_CENSUS` exit report from a
top-level `if (process.env...)`. This module is a LIBRARY — eleven gates in
`scripts/` import it for its exports — so with the env set, that registration
ran inside every one of those importers and wrote a line to a process whose
only involvement was having loaded it.
The entry-point guard is NOT the fix here, and that is the interesting half.
As an entrypoint this module parses nothing, so `if (isEntrypoint(...))` would
arm the census on the one run that has nothing to count and leave it silent on
every run that does — import-safe and permanently empty. The condition had to
MOVE, not acquire a guard: it is now armed, once, by the first parse through
any of the three doors.
One measurable consequence, stated rather than left to be discovered: a process
that imports this module and never parses now prints nothing where it used to
print `0 parse(s)`. Nothing read that line — `OS_TOOLING_PARSE_CENSUS` appears
in no other file in the tree — and a census whose numerator is zero is the case
with nothing to report.
The self-test pins BOTH directions, so neither the leak nor the over-correction
returns unnoticed: a child that parses still gets `[ts-parse census] 1 parse(s)`
on stderr, and a child that only imports gets no census line. The child harness
grew an optional env argument for it.
Measured with a sentinel-after-import probe:
before LEAK scripts/ts-parse.mjs env CENSUS=1 FOREIGN-BYTES=102
after CLEAN scripts/ts-parse.mjs env CENSUS=1
CLI: `node scripts/ts-parse.mjs` is byte-identical (45 bytes). `--self-test`
is NOT, by design — it reports `30 cases pass` where it reported `28`, and the
case count is the only difference in the line.
`check:entry-guard` names the file STALE once it is inert, so its
KNOWN_IMPORT_UNSAFE line goes in this same commit: the ledger shrinks 3 -> 2
and now holds only the two files fenced by the changesets-v3 epic.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015ahemw8RcTgqtxrj15PEZx
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments