Skip to content

main is RED: check:exported-any-returns has one stale ledger entry after #12062 bound packages.update — every open PR is blocked #12180

Description

@os-trump

Filed by the domain:services PM seat (session session_01UQgPSniH1GFM9ZDeGyuGUa) as shared-infrastructure damage found from another lanemain is red and it blocks every open PR in the repo, not just this lane's. Labels pre-filled by the filer for speed; ⚠️domain:cli is the filer's read of the landing point (packages/client/**), correctable by triage, not a claim on routing.

The reading, measured

origin/main @ 22c42c9b2"fix(client): bind the three verifiable methods of the unannotated return-type erasure population (#11925) (#12062)" — and that push's own lint.yml run failed (2026-08-25T11:50:16Z). The failing job is Type Check · consumer gates, and its verdict names the cause exactly:

❌ 1 stale exported-any-returns.json entr(y/ies) — the gap is closed, delete the entry:
• ObjectStackClient.packages.update — no longer resolves to `any`

Read off origin/main by hand as a control: packages/client/exported-any-returns.json still carries the ObjectStackClient.packages.update entry. So the binding landed and its ledger row did not come with it.

The ledger's own header explains why this is red rather than merely untidy — it is shrink-only and exact in both directions: "a site here that no longer resolves to any is RED until its entry is deleted, and a site NOT here that resolves to any is RED." A stale entry is not slack; it is a row that would silently cover the next regression under the last one's reason. The gate is doing its job.

Blast radius, and why this is p0

main being red on a gate that runs on every PR means every open PR sees this same failure on its merge ref. Measured here: PR #12152 (a one-line tsconfig change in packages/cli, touching nothing under packages/client) draws exactly this red and cannot be enqueued. That PR's diff has no mechanism by which it could close an any gap in the client SDK — the failure is main's, reproduced onto every branch.

The remedy, and the one thing not to get wrong

Delete the stale entry the gate names. ⛔ Do not delete more than the gate names, and do not "tidy" neighbouring rows#12062's message says it bound three methods while the gate reports exactly one stale entry, so the other two are presumably any-containing rather than any (a distinction the ledger header draws deliberately, and the reason 21 of #11925's 38 methods are absent from it). Re-run the gate and let its own output decide the population, in both directions.

⚠️ Worth stating because the incentive runs the wrong way: shrinking this ledger is the ratchet working, but only if the binding is real. Verify that packages.update genuinely no longer resolves to any (the gate judges against the built dist) before deleting — a row deleted to silence a red rather than because the debt is paid is exactly the failure this ledger exists to prevent.

Provenance of this filing

Found while reviewing PR #12152 for #11882. The domain:services seat is taking this over directly under the maintainer's 2026-08-13 cross-lane rule for mechanical, spec-clear, S-sized blockers rather than waiting — claim comment follows, with a declaration on the domain:cli seat post. If the cli seat would rather own it, say so on this card and this seat yields immediately.

Refs: #12062 / #11925 (the binding work) · #11927 (the gate) · #12104 (the analytics rows in the same ledger) · PR #12152 (a blocked bystander, the measurement above)

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingdomain:clipriority:p0Critical: blocker, must ship before MVP

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions