fix(1161): bound each /object_info transport so a hung route falls through to the one that works

[artokun]

Closes #1161. Replaces #1178, which is left open as the record of three approaches that were ruled out.

The bug

After a ComfyUI restart the tab can hold a half-open connection, so api.getNodeDefs() never settles — it does not throw, it simply never answers. Every await in the /object_info oracle was unbounded, so it parked on the first transport forever. Every command that consults it hung until the caller's 30s timeout: graph_set_widget, graph_remove_widget, and graph_get_object_info (which calls the oracle directly, with no cache in front).

fetchWholeObjectInfo already had a second transport — the raw GET /object_info, added by #982 for exactly this failure, and the very request the original reporter ran by hand to prove their backend was fine. It was never reached, because nothing gave up on the first one.

Why the bound sits here and not on the cache

Three rounds on #1178 established that bounding the cache cannot fix this: a bound one layer above the oracle can only choose how to fail, so the reported hang stayed in place under a different name. Bounding the transports is what makes the fallback reachable, which turns a hang into a successful write.

What ships

A single deadline for the whole question (OBJECT_INFO_DEADLINE_MS = 20000), spent down by each of the three I/O steps (client route, response, body) — not a per-step bound, which would multiply into a worst case nobody chose.

The accounting deliberately does not trust the clock:

• Each step gets a grant, and cannot outlast the grant its timer enforces in real time regardless of what now() reports.
• A timeout charges the full grant — the one real-time measurement here that cannot lie.
• A step that answered charges min(measured, grant); 0 is measurable, negative/NaN is charged in full.
• The fallback's floor holds by construction: the client route is granted at most deadline - consumed - FLOOR, so deadline - consumed >= FLOOR when the fallback is reached.

Refusals name each step's own share rather than the whole deadline, because quoting a wait that never happened is #982's own defect.

What it took to get here, recorded honestly

Six review rounds. The last three each found a P1 in code I had already called correct:

1. A subtracted reserve let a hung client route consume the whole budget, so the fallback was never issued — fetchApi call count 0. The suite was green because the test harness fired injected timers without advancing the clock, a state production cannot reach.
2. A backwards clock jump refunded the budget, letting one call run ~50s against a 20s deadline — past the bridge's 30s timeout, reproducing the original symptom.
3. A high-water ratchet, tried as the fix for (2), samples only at step boundaries — a jump between samples still refunds, and the test for it passed with or without it.

Separately, a ~14.5s payload figure in the header turned out to measure /object_info plus the combo refresh, not the download. The download is 167ms (#767). I introduced that number, and later reviews cited my own comment back as the repo's measurement. The header now says which figure measures what.

Verification

Live, against a 4304-type install with the real payload and fetchApi counted:

client route	fallback issued	elapsed	types
healthy	0	345ms	4304
throws	1	367ms	4304
hangs (the P1)	1	11.7s	4304

Unit suite 4115 pass / 0 fail. Mutations verified caught: zeroing the timeout charge, treating 0ms elapsed as unmeasurable, removing the floor, dropping the body's not-attempted branch.

Knowingly left open

• usableDefs diverges from main on an uninspectable payload (main returns the fallback's schema, this returns defs: null). Fail-closed is right, but it is a behaviour change and should be read as one.
• The deny-all widening the header documents: a filtering client that is merely slow can be overridden. Deliberate, recorded, and the exposure window is the client route's share, not the deadline.
• Sibling unbounded api.getNodeDefs() call sites — graph_add_node and panel_refresh_nodes still hang on the same socket. Filed as graph_add_node and panel_refresh_nodes still hang on the half-open socket #1161 fixed for set_widget #1180 rather than folded in here, because add_node uses a per-class route set_widget structurally cannot.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[artokun]

Review outcome: right layer, real hole — 11 CONFIRMED

The layer choice holds: bounding each transport is what makes the #982 fallback reachable, and reviewers confirmed it repairs three commands rather than one (graph_get_object_info calls the oracle directly, with no cache in front). But the change as written breaks a documented invariant, and that needs deciding rather than patching.

The deny-all override (CONFIRMED, reproduced)

This module's header states the fallback is consulted only when the client route returned NOTHING usable, "so it can never override a narrower answer the client actually gave".

A timeout breaks that. Reproduced with injected timers: a getNodeDefs that resolves the deny-all {} after the bound is abandoned, and the raw route's full schema is used instead. A client that filters deliberately and is merely SLOW — not broken — has its deny-all replaced by the broader schema, and a write is authorized against types it meant to withhold.

That is a genuine trade, not an oversight to fix quietly:

• Falling through is what fixes the P1, and treats "did not answer in time" as "did not answer".
• Refusing instead restores the invariant and puts us back where test(1178): pin why the /object_info bound cannot live in the burst cache #1178 was — choosing how to fail.

The honest resolution is probably to fall through and record the widening explicitly, which is exactly what this file already does for the analogous TTL race ("a real widening of an existing race… recorded here rather than waved past"). But that is a deliberate weakening of a stated guarantee, so it belongs in the open rather than inside a fix for something else.

Also confirmed

• The bound's justification cites the wrong measurement. 6000ms is defended with a 167ms figure, but that measures a fast LAN response, not the 5.4MB transfer this bound actually covers. A remote or tunnelled install that previously succeeded slowly now gets a hard refusal.
• ** / are outside any exception guard** since the try/catch was replaced, so a throwing accessor rejects out of the oracle instead of becoming a failure entry.
• ** and set_widget's combo-refresh fallback are still unbounded**, so the same half-open socket still hangs them. The fix is inconsistent across commands sharing one failure mode.
• My comment says the worst case is two bounds; the code has three (client route → response → body ≈ 18s against a 30s command budget).
• **Every new test hardcodes **, so the production default is uncovered — setting it to 0 would disable the bound and leave the suite green. This is the identical weakness I corrected in the cache tests two rounds ago and repeated here.

Where this leaves it

Still draft. The diagnosis and the layer are settled; what remains is one deliberate decision (accept and document the narrowing-override widening, or keep the invariant and accept a refusal) plus four mechanical corrections. I am not making that call inside a fix for a different bug.

[artokun]

(Correcting the comment above: I posted it through a shell heredoc and the backticks were executed as command substitution, so three bullets lost the code identifiers they named. The full text follows — the mangling is mine, not the review's.)

Review outcome: right layer, real hole — 11 CONFIRMED

The layer choice holds: bounding each transport is what makes the #982 fallback reachable, and reviewers confirmed it repairs three commands rather than one (graph_get_object_info calls the oracle directly, with no cache in front). But the change as written breaks a documented invariant, and that needs deciding rather than patching.

The deny-all override (CONFIRMED, reproduced)

This module's header states the fallback is consulted only when the client route returned NOTHING usable, "so it can never override a narrower answer the client actually gave".

A timeout breaks that. Reproduced with injected timers: a getNodeDefs that resolves the deny-all {} after the bound is abandoned, and the raw route's full schema is used instead. A client that filters deliberately and is merely SLOW — not broken — has its deny-all replaced by the broader schema, and a write is authorized against types it meant to withhold.

That is a genuine trade, not an oversight to fix quietly:

• Falling through is what fixes the P1, and treats "did not answer in time" as "did not answer".
• Refusing instead restores the invariant and puts us back where test(1178): pin why the /object_info bound cannot live in the burst cache #1178 was — choosing how to fail.

The honest resolution is probably to fall through and record the widening explicitly, which is exactly what this file already does for the analogous TTL race ("a real widening of an existing race… recorded here rather than waved past"). But that is a deliberate weakening of a stated guarantee, so it belongs in the open rather than inside a fix for something else.

Also confirmed

• The bound's justification cites the wrong measurement. 6000ms is defended with a 167ms figure, but that measures a fast LAN response, not the 5.4MB transfer this bound actually covers. A remote or tunnelled install that previously succeeded slowly now gets a hard refusal.
• The res.ok and res.status reads are outside any exception guard since the try/catch was replaced, so a throwing accessor rejects out of the oracle instead of becoming a failure entry.
• graph_add_node and set_widget's own combo-refresh fallback are still unbounded, so the same half-open socket still hangs them. The fix is inconsistent across commands sharing one failure mode.
• My comment says the worst case is two bounds; the code has three (client route → response → body ≈ 18s against a 30s command budget).
• Every new test hardcodes waitMs: 6000, so the production default is uncovered — setting OBJECT_INFO_TRANSPORT_WAIT_MS to 0 would disable the bound and leave the suite green. This is the identical weakness I corrected in the cache tests two rounds ago and repeated here.

Where this leaves it

Still draft. The diagnosis and the layer are settled; what remains is one deliberate decision — accept and document the narrowing-override widening, or keep the invariant and accept a refusal — plus four mechanical corrections. I am not making that call inside a fix for a different bug.

[artokun]

Addendum — I understated two of these

The full review returned 22 verified findings across eight defects. Two are worse than I described.

The bound is calibrated against the wrong measurement, and the repo already measured the right one

I justified 6000ms by citing /object_info at ~167ms. That figure is a fast LAN response. The thing this bound actually covers is a 5,413,770-byte download — and this repo has measured that: ~14.5s (#610).

So 6s does not merely risk refusing a slow install. It refuses a normal one. And because withTimeout deliberately does not cancel, the failure mode is worse than a refusal:

api.getNodeDefs() is streaming normally and would have completed at 9s; it is abandoned at 6s, the fallback starts a second 5.4MB download of the same payload that now contends with the first for the same link, its body bound fires at 12s, and the write is refused — on an install where the same write previously succeeded at 9s, well inside the 30s budget. The user pays 10.8MB of transfer for the refusal.

That is my error twice over: I reasoned from a number that measured something else, and I wrote a comment asserting the headroom was "generous rather than tight" on that basis. The right bound has to come from the payload measurement and the caller's real budget, not from matching the startup seed's 8s by analogy — which is the same reasoning-by-similarity that produced three dead ends on #1178.

fetchWholeObjectInfo can now REJECT, and two callers have no catch

I described this as a throwing-accessor edge case. It is a contract break, proven by running main and HEAD side by side:

• a response-like object with a throwing ok accessor: main returns a failures list; HEAD rejects
• a Proxy whose ownKeys trap throws (reached through usableDefs): main returns a failures list; HEAD rejects

The file states the contract two screens up — "every failure path returns defs: null". Replacing both try/catch blocks re-protected only the awaits, leaving the post-await inspections (res.ok, res.status, Object.keys inside usableDefs) unguarded.

graph_remove_widget and graph_get_object_info both await this with no try/catch of their own, so instead of the documented refusal the agent receives a raw unhandled error. A custom-node extension that monkey-patches app.api.fetchApi and returns a lazily-evaluated or proxied response is enough to trigger it.

Where this leaves the branch

Not mergeable as written, and the remaining work is now specific rather than exploratory:

1. Re-derive the bound from the ~14.5s payload measurement and the 30s command budget — not from the seed's 8s.
2. Restore the resolve-always contract by guarding the post-await inspections.
3. Decide the deny-all override explicitly (accept and document the widening, or keep the invariant).
4. Bound the four sibling api.getNodeDefs() call sites so graph_add_node stops hanging on the same socket.
5. Cover the shipped constant in tests, so zeroing it cannot leave the gate green.

The layer is right and the diagnosis has held across four rounds. The calibration and the contract are what remain, and both are mine.

[artokun]

Round 5: 18 CONFIRMED. I am stopping here rather than attempting a sixth.

Every candidate I flagged was confirmed, several by running main and this branch side by side. The remaining defects are real and I could keep patching them, but the pattern across five rounds is the useful information, and it says the next patch would introduce the next hole.

Why I am handing this over instead of continuing

Rounds 1–3 bounded the cache; each version traded one permanent-refusal case for another. Round 4 moved the bound to the oracle — the right layer — and broke the resolve-always contract. Round 5 fixed the calibration and the contract, and:

• the resolve-always fix is still incomplete — I guarded the property reads but not their uses: ${responseStatus} is stringified outside the try/catch, describeFailure can throw on a hostile rejection value, and now()/remaining() are themselves unguarded expressions between awaits;
• remaining() re-implements get-errors-budget.js's getErrorsStepBudgetMs, dropping its per-step clamp and broken-clock handling — the second time this issue I hand-rolled something the repo already had, after bounded-step.js;
• guarding usableDefs changed behaviour versus main, verified side by side: an uninspectable payload now takes the deny-all branch and suppresses the fallback, where main returned the fallback's schema;
• a step reached with no budget reports "did not answer within the budget" for a request that was never issued — a false statement in a refusal a user reads;
• Date.now() is non-monotonic, so a wall-clock jump makes every step report a timeout;
• 20s + the 8s seed wait leaves ~2s of the bridge's 30s command budget.

That is not a fix converging on correctness. It is one that finds a new invariant every round, in a file whose header documents four of them and whose siblings document more.

What I believe the right next step is

Not another revision of this branch. The evidence says:

1. Use the existing primitives. bounded-step.js for the wait, get-errors-budget.js for the per-step budget. Two rounds were spent re-deriving these badly. Neither was found by searching; both were found by review.
2. Make the resolve-always contract structural, not a guard per expression. Every round has added a try somewhere and missed the next expression. Wrapping the whole body once and converting any throw into a failures entry would satisfy the documented contract by construction — which is what "every failure path returns defs: null" actually asks for.
3. Decide the deny-all question deliberately. A timeout treating a slow filtering client as "answered nothing" widens a stated invariant. I documented it; it should be decided, and the decision belongs to whoever owns that guarantee.
4. Size the budget against the whole write path, not the oracle alone — the seed wait sits in front of it.

What ships from this issue regardless

Nothing yet, and that is the honest outcome. The diagnosis is solid and has held across all five rounds: api.getNodeDefs() can hang, the oracle awaited it unbounded, and the #982 fallback was therefore unreachable. Three commands are affected — graph_set_widget, graph_remove_widget and graph_get_object_info, the last calling the oracle directly with no cache in front. Four sibling api.getNodeDefs() call sites, including graph_add_node, have the same unbounded await and are untouched by any version of this.

Both branches stay open as the record: #1178 for the three cache-layer approaches that were ruled out, and this one for the layer that is right and the four invariants it has to satisfy at once.

[artokun]

Correcting my own handoff: the branch did not fix the P1, and my test hid that

The comment above says "the layer is right and the diagnosis has held across four rounds," and that the calibration and the contract were all that remained. That was wrong about the thing that matters most, and round 5 proved it by execution rather than by reading.

The fallback was never issued at all

The single shared 20s deadline was consumed entirely by the hung client route. withTimeout can only fire at the deadline, so by the time the fallback was reached remaining() was already <= 0, runTransport took its early exit, and the raw GET was never sent — fetchApi call count 0.

So the branch converted a 30s hang into a 20s refusal with the P1 fully intact. Worse, the refusal then read GET /object_info did not answer within the 20000ms budget for a route nothing had contacted — reintroducing #982's original defect (a refusal asserting a cause it never established) inside the fix for #982's other half.

My flagship test passed in a state production cannot reach

The harness fired the injected timer without advancing the clock remaining() reads. A timer armed for ms only fires once ms has elapsed, so every test ran with the full budget still unspent — which is why the suite was green while the fallback was never sent. A sibling test (the budget is shared) pinned the opposite, real outcome; I read that as two tests covering two cases rather than as a contradiction.

What changed in cad2ea86

• A reserved floor. Each step spends at most what is left minus a reserve for the steps after it; the client route may take half, so the fallback always has the other half — enough to attempt the ~14.5s payload on its own.
• NOT_TRIED is its own outcome. A step reached with no budget says so in its own words instead of borrowing the timeout's.
• The harness owns the clock and advances it when a timer fires. With the reserve zeroed — the code exactly as reviewed — 4 tests fail, including the flagship. That is the check the previous version could not perform.
• Two more contract breaks, both verified by running the previous commit side by side, where it rejected out of a module whose header promises every failure path returns defs: null:
  • ${responseStatus} interpolates below the guard, so Object.create(null) as a status rejected with TypeError: Cannot convert object to primitive value.
  • describeFailure called String(err) outside every guard, so a thrown value with a throwing toString escaped. It now resolves and the fallback still answers, so a hostile error value no longer costs the user their write.

Full suite: 4110 pass, 0 fail.

What I am still not claiming

• usableDefs still diverges from main on an uninspectable payload: main returns the fallback's schema, this returns defs: null. I believe fail-closed is right and the test says why, but it is a deliberate behaviour change and should be read as one, not waved through.
• The deny-all widening documented in the module header is still a deliberate weakening of a stated guarantee.
• Four sibling api.getNodeDefs() call sites remain unbounded, so graph_add_node still hangs on the same socket.
• The suite is green, which is exactly what it was last round while the fallback was unreachable. It is now green for a reason I have checked by mutation rather than by reading, but that is the correction's own limit.

Still draft. The two open decisions above are not mine to make inside a fix for something else.

[artokun]

Browser-verified against a live install — the fallback is now actually sent

Run in the ComfyUI page against the served bundle (the junction serves this working tree, so this is the branch code), on a 4304-type install with the real ~5MB payload. getNodeDefs replaced with the production failure shape; fetchApi is the real api.fetchApi, counted.

client route	fallback issued	elapsed	types returned	recorded failure
hangs (never settles — the #1161 P1)	1	10.4s	4304	did not answer within its 10000ms share of the 20000ms budget
throws (half-open socket)	1	806ms	4304	threw: half-open socket
healthy	0	366ms	4304	(none)

The first row is the one that matters: the previous commit produced fetchApi call count 0 on that exact input. The write now succeeds instead of the command hanging to its 30s timeout, and the healthy path costs no extra request.

What the live run caught that the suite did not

The hung-route refusal read "did not answer within the 20000ms budget" for a step that waited 10000ms — the client route is capped at half. Quoting a number that was never spent is #982's own defect, a refusal asserting what it did not establish, and I had reintroduced it in the message while fixing it in the logic. Fixed in 32b83abe; each step now names its own share and the whole budget, and a test pins that the un-spent whole is not quoted as the wait.

Also on the branch since the correction above:

• 57607e5b — the reserve became a floor (max(left, floor)) rather than a subtraction. Measured at small deadlines, per-step overhead alone overran the subtraction and the fallback was skipped again — the same defect through another door. Response and body now share one end time, so a stalled body cannot restart the clock and the worst case stays at a single deadline. Removing the max() fails the suite.

Full suite: 4112 pass, 0 fail. A review of these commits is running.

The two open decisions from the correction are unchanged and still not mine to make here: the usableDefs divergence from main, and the documented deny-all widening. The four unbounded sibling api.getNodeDefs() call sites (graph_add_node) also remain out of scope for this PR.

[artokun]

Round 6: the clock stopped being the safety mechanism

The previous review found the oracle could run ~50s against a 20s deadline: spent() clamped a backwards Date.now() jump per reading, which silently refunded everything already spent, so each later step redrew a full budget. graph_set_widget waits on the history seed (8s cap) in front of this, so the command overran the bridge's 30s timeout and produced a bare timeout naming no routes — the #1161 symptom itself, reintroduced by the fix for it.

I tried a high-water ratchet first and rejected it: it samples only at step boundaries, so a jump between samples still refunds — and the test I wrote for it passed with or without the ratchet, which is how I caught that it wasn't a fix.

What replaced it

The safety property no longer reads the clock. Each step is handed a grant, and a step cannot outlast the grant its timer enforces in real time regardless of what now() believes, so bounding the sum of grants bounds the call.

• A timeout charges the full grant — the one real-time measurement here that cannot lie. This closed a case the new test caught immediately: with a stalled clock (coarse resolution, frozen VM clock), three hung steps ran 9000ms against a 6000ms deadline while now() reported zero throughout.
• A step that answered charges min(measured, grant); 0 is measurable, anything negative or NaN is charged in full.
• The floor is now arithmetic, not a max(): the client route is granted at most deadline - consumed - FLOOR, so deadline - consumed >= FLOOR when the fallback is reached.

Also fixed from that review

• The body's NOT_TRIED branch was untested — deleting it left the suite green while converting a resolve-always module into a TypeError rejection for two callers that have no catch. Pinned; the mutation now fails.
• The four-branch demux was hand-written at all three call sites, where omitting a branch throws ("err" in outcome on a Symbol) rather than misbehaving quietly — a bug I shipped once already this issue. One outcomeKind() now holds the dangerous test.
• The header documented the deny-all exposure window as "slower than the budget" (20s) when the split caps the client route at half that. The window was twice what was written; it now names the share.

Live verification (4304-type install, real payload, fetchApi counted)

client route	fallback issued	elapsed	types	recorded failure
healthy	0	345ms	4304	(none)
throws	1	367ms	4304	threw: half-open socket
hangs (the P1)	1	11.7s	4304	did not answer within its 10000ms share of the 20000ms budget

10s for the client route's share plus ~1.7s for the fallback, inside the 30s command timeout, and the healthy path still costs no second request.

Mutations verified caught: zeroing the timeout charge, treating 0ms elapsed as unmeasurable, removing the floor, dropping the body branch. Suite 4115 pass, 0 fail.

Still open, still not decided here

The usableDefs divergence from main on an uninspectable payload, and the deny-all widening the header documents. Both are deliberate and both are recorded; neither belongs to me to settle inside a fix for a different bug. The sibling unbounded call sites are now #1180.

A review of this redesign is running. Not merging until it clears — the last two rounds each found a P1 in code I had already called correct.

[artokun]

Round 7: five CONFIRMED, and the fix was to stop measuring

The review of the grant-accounting commit confirmed by execution that its headline claim was false in both directions. Only steps that TIMED OUT were charged their grant; a step that ANSWERED was still charged whatever now() reported.

clock behaviour	real elapsed vs a 20,000ms deadline
frozen (VM suspend, clock-shimming extension)	49,998ms
ticking at 0.1x real rate	46,091ms
one −9,990ms NTP/DST correction mid-call	29,990ms

graph_set_widget burns up to 8s on the history seed before this even runs, so those overrun the bridge's 30s command timeout and produce a bare timeout naming no routes — the #1161 P1 itself, produced by its own fix.

And a regression in the other direction: the "unmeasurable elapsed" arm charged an answering step its entire remaining grant, so one backwards or NaN reading during a healthy 450ms response left the body unread and refused the write. The parent authorized the identical input.

What changed

Three designs in a row tried to make an untrustworthy Date.now() safe — clamping negative readings, a high-water ratchet, charging measured elapsed — and each moved the hole rather than closing it. So this one does not measure.

Every step is charged its full grant, unconditionally. A step cannot outlast the grant its timer enforces in real wall time, whatever now() reports, so grants summing to the budget bound the call with no clock in the argument. The module no longer reads a clock at all.

Shares replace the floor, and cover the step the floor missed: client ½, response ½ of the remainder, body the rest — 10s/5s/5s on the shipped budget. Reserving for the fallback but not for its body was the same starvation defect one level down; review confirmed a response that used everything left the body unreadable after a 200 OK.

A non-finite deadlineMs made consumed infinite and every later grant NaN — and Math.max(0, NaN) is NaN, not 0, so the fallback was skipped entirely (call count 0). My first normalisation, non-finite → zero, merely relocated the damage: the oracle then attempted nothing. A value that cannot be a budget now takes the shipped default; an explicit non-positive number is obeyed and says so.

The tests were vacuous for the third time this issue

The clock test could not fail for the reason it named — every step in it timed out, where the charge was already clock-independent — and the load-bearing Math.min(elapsed, grant) cap survived mutation with all 39 green.

The suite now passes a clock that throws. If the call resolves, the accounting provably never read it, and no later edit can reintroduce a clock read silently.

Re-measured

clock	before	after
frozen	49,998ms	20,000ms
0.1x	46,091ms	20,000ms
−9,990ms jump	29,990ms	20,000ms
throws	—	20,000ms

Fallback issued in all four. Live against the 4304-type install: healthy 777ms / 0 extra requests; throws 350ms; hangs 10.5s with 4304 types recovered; hangs + throwing clock 11.0s, same result.

Suite 4117 pass / 0 fail. Mutations verified caught: not charging the grant, giving the client route the whole budget, leaving the body no share, dropping a demux branch.

outcomeKind is now pinned directly against both Symbols, because the share model makes "not-tried" unreachable through the public API while leaving the branch live — and a missed branch there throws.

A review of this commit is running. Still draft.

[artokun]

Round 8: a shipped regression, and a mistake three rounds old

Charging every step its full grant bounded the total but stranded the time a fast step never used. Reproduced by execution against this branch, its parent, and main:

scenario	parent / main	previous commit
client 200ms, headers 300ms, body 7000ms (5.4MB over a tunnel)	ANSWER at 7.5s	REFUSED at 5.5s
client 200ms, headers 6000ms, body 500ms (backend busy)	ANSWER at 6.7s	REFUSED at 5.2s

The second refused with 14.8s of a 20s budget never granted to anything. The client route is normally present and fast-failing, so this was the common path — the third consecutive round where the regression ran in the same direction: refusing what main serves.

The mistake

Every scenario that broke the three earlier clock-based designs — an NTP step correction, a DST or manual change, a VM suspend/resume, a frozen reading — is a wall-clock hazard, and the default was Date.now().

I concluded "stop measuring." The available conclusion was "stop measuring with the one clock in the platform that is allowed to lie."

performance.now() is monotonic by specification, and this repo already measures its other elapsed-time windows on it — monotonicNow() in the panel, session-rebind.js, reconnect-staleness.js, all of which say so in their comments. I removed a clock when the repo had already made the correct choice three times over.

What ships now

• A step that times out is charged its full grant, with nothing measured — the timer is real-time truth.
• A step that answers early is charged min(measured, grant) on the monotonic clock, so it hands back what it did not use.
• The cap stops a hung client route starving the fallback (the original P1); the reclaim stops a fast one spending time it never used. Both halves are pinned separately, because each was broken on its own during this issue.
• Reading an injected clock is wrapped — now is caller-supplied and an unreadable clock must not reject out of a module documented to always resolve. An unusable reading charges the full grant, so the error is always conservative.
• The reclaim is clamped to the grant: a forward jump would otherwise charge a billion milliseconds and skip the fallback — the call-count-0 signature arriving through the reclaim instead of the cap. That mutation survived my first pass and is now caught.

Also fixed this round

• Math.floor(left * share) truncated grants to 0 below 3ms, so nothing was contacted and the refusal named a cause that never occurred ("the budget was already spent" with consumed at 0) — panel_set_widget cannot validate subgraph widget after restart despite bound live graph #982's defect again.
• timers: null rejected; only undefined reaches withTimeout's default.
• The header still claimed the smallest share is 10s after the body got its own — it was 5s. Same stale-number trap as the ~14.5s figure, in the same file. The split is now spelled out so a change must update it, with a cross-reference explaining why get-errors-budget.js cites 14.5s correctly (it bounds the forced refresh; this bounds only the fetch).

Verified

All three regression scenarios ANSWER again at main's timings. Live on a 4304-type install: healthy 782ms / 0 extra requests; client returns null 334ms (the regression check — it now costs almost nothing); throws 333ms; hangs 10.8s with 4304 types recovered; hangs + throwing clock 11.4s, same result.

Suite 4122 pass / 0 fail. Six mutations verified caught: removing the reclaim, removing the timeout charge, dropping min(spent, grant), dropping max(1, …), unwrapping the clock read, and each share value.

A review of this commit is running. Still draft.