Every queued binding-removal PR records an absolute workspace count; six are stale and the two correct ones collide with each other #10739

Activity

1. proggeramlug

   added

   package-auditFound by the 2026 package audit: compiling real npm packages from source instead of native bindingsFound by the 2026 package audit: compiling real npm packages from source instead of native bindings

   on Sep 19, 2026
2. proggeramlug commented on Sep 19, 2026

   

   proggeramlug

   on Sep 19, 2026

   ContributorAuthor

   More actions

   Queue status update: every enabling fix is now on main, so the whole removal queue is unblocked.

   All five were closed with an empty mergedAt, which is the merge-train signature (a train lands the code under its own PR and closes the sources), so "closed, not merged" reads as unlanded if you go by the PR state alone. Verified by content on origin/main rather than by PR status:

   fix	verified on main
   #10668 http client surface	b36554a2d7 + changelog.d/10668-http-client-response-surface.md
   #10673 namespace/export =	13615eb471 (train 223) + fragment
   #10674 cjs conditional require	changelog.d/10674-cjs-conditional-require-deferred.md
   #10675 dyn_eval class expressions	02a3b6ab5f, a5583cfb3f + fragment
   #10699 import provenance	8e59526ac1, 0900ce4d03 + fragment

   So the "do not merge before #N" note on each removal is now satisfied for all of them. What remains for each is mechanical but not optional:

   1. A real rebase onto main — each is stacked on a branch that squash-merged, so its base commits no longer exist as such and a merge will not do.
   2. A count recompute per the table above.
   3. A re-run acceptance check (plain import, no compilePackages entry, byte-compared against Node 26.5.1).

   One sequencing point worth stating, because it determines how fast this queue can actually move: rebasing them all now would be wasted work. Every removal edits the same registry surfaces and shifts the same absolute counts by one, so the moment any one lands, the other six are stale again — in their counts if not in their conflicts. The queue can only advance at one rebase per landing. Rebasing ahead of that does not buy parallelism; it buys rework.

   Done so far under that protocol: #10691 (dotenv) and #10701 (uuid) are rebased, MERGEABLE, and carry correct counts against today's main — though they collide with each other, so the second to land needs 79→78 / 30→29. #10679 (axios) is rebased and MERGEABLE but still carries stale counts; that is being fixed.
3. proggeramlug commented on Sep 19, 2026

   

   proggeramlug

   on Sep 19, 2026

   ContributorAuthor

   More actions

   The same mechanism exists in a second file, and there it is already self-inconsistent.

   scripts/native_result_ledger.py carries EXPECTED_ROWS, another absolute. Read from each head against main 023dc0b653:

   ref	EXPECTED_ROWS	tsv lines
   main	371	323
   #10677 pg	371	323
   #10693 nanoid	371	323
   #10679 axios, #10701 uuid	371	323
   #10680 mysql2	343	309
   #10704 decimal	359	311

   #10680 removes 28 provider rows and #10704 removes 12, each computed from 371. They collide directly: after #10680 lands, #10704's base is 343, not 371, so its recorded 359 is wrong by the size of the other PR's removal.

   It is worse than that, because main's 371 is itself wrong — see #10738, where the true count is 376. So both numbers are derived from a base that was already stale, and once #10738's fix lands (correcting the constant and adding four newly-classified rows) both are wrong again by a different amount.

   Two consequences for sequencing:

   1. Land native_result_ledger.py is red on pristine main (expected 371, found 376), and its path filter means it can only fail on an unrelated PR #10738's fix before any removal that edits the ledger, so removals rebase onto a ledger that is correct and fully classified rather than each re-deriving a decrement from a base that is wrong by five.
   2. The "recompute from the resolved tree, never by arithmetic from the old figure" rule applies to EXPECTED_ROWS exactly as it does to workspace_members. Any removal deleting native providers must recount, not subtract.

   Worth recording the more general shape, because it is what made #10738 dangerous rather than merely untidy: the stale constant was load-bearing as a mask. The row-count check ran first and failed, so the classification-coverage check never ran, and four providers with no classification at all sat behind it. Bumping the constant alone would have turned the gate green and shipped the real defect — an unclassified result_kind misrepresents to the GC what a native call returns. A gate that stops at its first failure reports one defect and conceals the others, and there is no reason the concealed one should be the less serious.
4. proggeramlug commented on Sep 19, 2026

   

   proggeramlug

   on Sep 19, 2026

   ContributorAuthor

   More actions

   Fourth file class hit by this mechanism, and this one nothing checks: the generated docs.

   While rebasing #10704 (decimal.js removal), docs/api/perry.d.ts and docs/src/api/reference.md both auto-merged with zero conflict markers. The merge was partly right — it correctly stripped decimal.js from the body — and silently kept main's stale header counts:

   file	after clean auto-merge	correct for the resolved tree
   docs/api/perry.d.ts	2067 / 132	2066 / 131
   docs/src/api/reference.md	3009 / 134	2983 / 132

   Caught only by regenerating from a fresh build rather than trusting the clean merge.

   This is the same shape as the workspace counts, one file class further out, and it is worse in one specific way: a body that is correct plus a header that is stale looks more trustworthy than either error alone. A reviewer scanning the diff sees the decimal.js entries correctly removed and reasonably concludes the file was handled.

   Running tally of surfaces this has now hit

   1. workspace-architecture.json — workspace_members / decision_counts
   2. scripts/native_result_ledger.py — EXPECTED_ROWS / EXPECTED_PROVIDERS
   3. scripts/unrooted_local_shape_baseline.json — per-file counts
   4. docs/api/perry.d.ts and docs/src/api/reference.md — header counts (new)

   The first three are gated: workspace_architecture.py --check, the ledger check, and the unrooted ratchet each fail on a stale value, so the error surfaces eventually even if late and on the wrong PR. The docs are the exception — nothing compares the committed file against a regeneration unless someone regenerates, so a stale header can land and stay.

   Two method notes from the same rebase, both worth generalising

   A count that decrements is not derivable by arithmetic. #10704 does decrement EXPECTED_ROWS/EXPECTED_PROVIDERS, unlike the axios/dotenv/uuid removals which touch no ledger rows. The correct values came out at 364 / 314, recounted from the resolved tree — not obtainable by subtracting the PR's old delta from main's new base, because the tree shape differs. Subtraction would have produced a plausible, wrong number.

   Re-derive a stale value even when it passes. unrooted_local_shape_baseline.json --check passed at 577 against a baseline of 578 — an improvement, therefore green. It was re-derived anyway. A technically-passing stale number is precisely how the ledger's 371 survived long enough to mask four unclassified result_kinds (#10738): the gate was green, so nobody looked.
5. proggeramlug commented on Sep 19, 2026

   

   proggeramlug

   on Sep 19, 2026

   ContributorAuthor

   More actions

   Two refinements from #10712's rebase, both sharpening what was written above.

   1. The docs staleness is not confined to the header counts. Regenerating docs/api/perry.d.ts in full — rather than patching the header line — also removed a stale declare module "commander" body block that the clean auto-merge had retained. A header-only correction would have produced a file with a correct count and a phantom module declaration in it.

   That matters for how the fix is framed. "Update the header after a removal" is not sufficient; the body carries removed surface too, and the two can go stale independently. The remedy is to regenerate from a fresh binary and diff, never to patch.

   2. The three-way consistency check caught a second instance, in a form the first one wouldn't have suggested.

   The check is sum(decision_counts) == workspace_members == len(crates) — three independent quantities that must agree. On #10712's second rebase round, workspace-architecture.json auto-merged with zero conflict markers and silently kept the stale 77/28/44 from round one. Critically:

   • sum(decision_counts) and workspace_members agreed with each other — both 77.
   • len(crates) was 76.

   So two of the three were mutually consistent and both wrong. A check comparing only the counts to each other passes; workspace_architecture.py --check alone did not catch it. The disagreement with the crate map is what surfaced it.

   That is the second defect this check has caught (the first being #10691's file, where the crate map had already shrunk to 77 while the counts still read 78) and it is now standard for every removal in this queue. Worth considering whether workspace_architecture.py --check should assert the three-way identity itself, since the data it needs is already in the file it reads — which would move this from a discipline someone has to remember to a gate that cannot be forgotten.

   Running tally of stale-merge instances caught on this campaign: five — #10679, #10691, #10704, #10708, #10712 — across workspace-architecture.json, native_result_ledger.py, unrooted_local_shape_baseline.json, the generated docs (headers and bodies), and Cargo.lock (a stale perry-ext-* entry surviving git checkout --ours, caught only by the next build regenerating it away).
6. proggeramlug

   added 7 commits that reference this issue on Sep 20, 2026

   fixup(rebase): re-derive every absolute count on the combined tree

   ...

   c2011ab

   chore(pg): remove native pg binding, compile real package from source (…

   ...

   6e0f111

   refactor(stdlib): remove mysql2 native binding (#10680)

   ...

   713b15e

   chore: re-derive every absolute-count surface for the combined pg + m…

   ...

   8e2a99e

   chore(10704): re-derive the ledger absolutes against the new main tip

   ...

   4c0dca0

   chore(train266): re-record the tokio inventory from the merged tree

   ...

   fdf3b25

   chore(train266): re-record the tokio inventory from the merged tree

   ...

   636beb9