fix: a governance server that hangs is worse than one that errors (#130, #131, #132)

[c-1k]

Closes #130, #131, #132.

usertrust-server v3.3.1 could not complete a single authorization in its default configuration. /v1/authorize never responded — not slowly, ever.

Root cause (#130)

tigerbeetle-node exposes no request timeout — ClientInitArgs is cluster_id + replica_addresses and nothing else — and it treats an unreachable or unresponsive cluster as transient: it retries the handshake forever and its promise never rejects. createTBEngine awaited that promise, so createGovernor({ dryRun: false }) never settled and every request behind it hung. dryRun: true skips engine construction entirely, which is why the one existing integration test passed.

The part worth naming: the catch around engine creation that raises LedgerUnavailableError — carrying the exact hint an operator needs — was unreachable in the most likely production misconfiguration, because there was no rejection to catch. The error existed; nothing could raise it.

Measured against the real native client:

Scenario	Outcome	Time
Healthy cluster (0.17.9)	createTreasury OK	0.7s
Nothing listening	retries ConnectionRefused forever	never settles
A foreign listener on the port	silent	never settles
Version-mismatched cluster	rejects "client evicted"	0.7s

Only the reachable-but-wrong cases ever failed loud.

On the reporter's machine the default TB port 127.0.0.1:3001 was held by an unrelated next-server — so the client connected at the TCP level and waited forever for a reply in a protocol the listener does not speak. Both modes hang, so the fix does not depend on which one you hit.

The fixes

#130 — tigerbeetle.connectTimeoutMs (default 5s) bounds the handshake, making the existing LedgerUnavailableError path reachable. A timed-out client is destroyed rather than left retrying behind a caller that has already given up. Applied verbatim to both governors; engine-factory-parity.test.ts compares them as source text.

#132 — a server-side deadline on every governor await. This is the class fix and it stands on its own: a cluster that dies after a governor is built stalls inside authorize(), where no construction-time deadline can see it. close() had the same defect — destroyAll() awaited the same never-settling promise, so a server whose ledger was unreachable could not shut down either.

Two traps this opened, both fixed here:

• Shadow mode swallowed anything that was not exactly 500. The moment a 503 existed, an outage would have been returned as a clean 200 {"decision":"would_deny"} — a dependency outage laundered into a policy opinion. Only 4xx verdicts are shadowed now.
• settle/abort deliberately bound only governor construction, not the settle/abort call: a timed-out settle has an unknown outcome on the money path, and reporting it as failed would invite a double-settle.

#131 — end-to-end coverage of the default config, in both directions. A failure-path test alone would be satisfied by a deadline that refuses everything.

Before / after — the issue's exact probe

before:  POST /v1/authorize -> TimeoutError after 90.0s   (no response, ever)

after:   POST /v1/authorize -> HTTP=503  time=3.028s
         {"error":"ledger_unavailable",
          "reason":"TigerBeetle createTreasury did not answer within 3000ms (addresses: 127.0.0.1:3001)"}

The reason string names the address, so the next operator diagnoses this from the response instead of from sample.

Measured under the real client bound (curl --max-time 5), which is the number that matters. The first version of this PR used a 5s ledger deadline and answered at 5.03s — and usertrust-claude-code aborts its HTTP request at 5s (hooks/lib.mjs:168; the 15s in hooks.json bounds the process, not the request). So the labelled 503 arrived after the client had stopped listening, and every user would have seen a generic transport error instead. Caught by the connector review on #135. The chain is now monotonic with headroom:

connectTimeoutMs (3s)  <  requestTimeoutMs (4s)  <  client HTTP (5s)  <  hook process (15s)

Same server against a real cluster, dryRun still false: authorize 200 in 0.70s → settle 200 with a real receipt and audit hash → budget 49980. Shutdown with an unreachable ledger: clean exit in 2s.

Mutation verification (by name, not count)

Mutation	Tests that fail	How
Revert both core+server fixes	integration.test.ts → "answers 503 when the ledger is unreachable…", "does not shadow a ledger outage…"	hang to ceiling
Revert core fix only	ledger-connect-deadline.test.ts → "rejects createGovernor with LedgerUnavailableError instead of hanging forever"	hang to ceiling
withDeadline → passthrough	the 3 "request deadline — a stalled governor answers…" tests	hang to ceiling

In every case the pre-existing dryRun test still passed — which is precisely the blind spot #131 is about. Each failure is a hang, i.e. the defect itself, not an incidental assertion.

Positive control: the full tb-integration job run locally against a real TigerBeetle 0.17.9 — 4 files, 12 tests, all green with the deadline armed. Without it, an always-refusing guard would have passed every failure test here.

Gates

• vitest run — 4373 passed, 0 failed, 15 skipped
• coverage gate at CI thresholds — exit 0
• biome check . — exit 0 (39 pre-existing warnings)
• tsc -b packages/core packages/server — exit 0
• tb-integration job locally against real TB 0.17.9 — 12 passed

Notes

• Two new config fields; ServerConfig gains requestTimeoutMs, so the five test config helpers were updated.
• Unrelated pre-existing flake observed: vault/derive.test.ts and cli/secret.test.ts (scrypt, vitest's default 5s timeout) time out under heavy load — reproduced at load average ~44, and identically on unmodified master. Not caused by this change, but worth raising separately now that the fleet runs many lanes at once.

🤖 Generated with Claude Code

---

Round 7 remediation — bad416f

Both open findings are closed. The two helpers now take a thunk, not a promise, so the
clock check happens before the work is started rather than after it was already issued; and
Deadline.run applies the same clock check on the failure path, which a rejection used
to skip by jumping out through finally.

Accepted cost, recorded deliberately: converting every late rejection to
GovernorTimeoutError loses one piece of operator detail. A late LedgerUnavailableError
names the TigerBeetle addresses in its reason string; past the budget that request now
reports governor_timeout instead. An on-time LedgerUnavailableError still surfaces
unchanged, and both map to 503, so only the reason string is lost and only on the late path.
The alternative — convert only what would map to <500, which is the shadow case
specifically — was rejected because it couples deadline.ts to HTTP status mapping. Keeping
the clock the single decider is worth the reason string. A permanent test,
"still reports an ON-TIME failure as itself", pins the half that must not change.

Known residual 2 is untouched and still open by design: Governor.abort() recording a
provider failure that never happened. It needs new Governor API plus a decision about which
audit event truthfully describes "hold released, no call attempted" — frozen-format
territory, out of scope for this round. Still written up in the server README.

[c-1k]

Codex gate — iteration round

command       codex review --base origin/master
model         gpt-5.6-sol
effort        medium
reviewed SHA  c86a50b5a38cbff6c03a170b4a2c565ed887059c
exit          0

Verdict: "The new deadlines can abandon successful late operations, leaking pending holds and live governors. These affect money accounting and shutdown behavior."

Not a no-op review — it named every changed file (govern.ts ×39, headless.ts ×25, server.ts ×20, pool.ts ×19, wire.ts ×13, deadline.ts ×11, plus both new test files).

Findings — both accepted and fixed in 6a5ccb8

Both are correct, and both are the same defect class as the bug this PR fixes: a deadline abandons an operation, it does not cancel it, so something real was created and then became unreachable. I verified each cited invariant in AGENTS.md rather than taking the citation at face value — both say what the review claims.

[P1] server.ts — authorizations that complete after the timeout. The ledger hold is real and its transferId reached nobody (the client got a 503), so nothing can ever settle or abort it. AGENTS.md:84-100 gives every hold exactly one terminal outcome, with no exception for "the server stopped waiting". Left alone, every timed-out authorize permanently retires part of the tenant's budget — a retry loop against a slow ledger exhausts the budget while every request reports a timeout. A hang traded for a slow leak.

[P2] pool.ts — governors that resolve after the shutdown deadline. Never destroyed. AGENTS.md:118-123 is explicit that an undestroyed TigerBeetle client is what keeps the event loop from draining — so this leak can stop the process exiting, i.e. the shutdown fix would have reintroduced the shutdown hang by another route.

Fixed in one place rather than two, since it is one shape: withDeadline now takes an onAbandoned continuation, attached before the race so nothing can land in the gap. A late rejection is swallowed deliberately — it produced nothing to reclaim, has no listener left, and would otherwise take the process down over a failure the caller was already told about.

Mutation-verified by name: removing only the reclamation, leaving the deadline itself intact, fails exactly "voids an authorization that lands AFTER the deadline gave up on it" and "destroys a governor that resolves after the shutdown deadline" — and nothing else. The surgical mutation is the point: the deadline tests still pass, so the two new tests are pinning the reclamation specifically.

Gates after the fix: vitest run 4375 passed / 0 failed, coverage gate exit 0, biome check . exit 0 (39 pre-existing warnings), tsc -b exit 0.

A max-effort certification round on the new SHA follows.

[c-1k]

Codex gate — max certification round

command       codex review --base origin/master
model         gpt-5.6-sol
effort        max
reviewed SHA  6a5ccb8e7b9991c74c6e6ca644c4e87e94662e0c
exit          0

Verdict: "Timeout cleanup can resurrect and leak the TigerBeetle client it intends to stop. The new server timeout also lacks a runtime default on the public programmatic path."

Named every relevant file (govern.ts ×144, headless.ts ×108, server.ts ×36, pool.ts ×31, deadline.ts ×20) — not a no-op.

Findings — both accepted and fixed in 7ac5b12

[P1] Teardown resurrected what it tore down. Closing the client makes tigerbeetle-node reject the in-flight request with Client was closed., which isConnectionError classifies — correctly — as a connection error. So withReconnect built a fresh client and retried. The destroy() I added to clean up a timed-out handshake was therefore leaving a brand-new client hammering the same dead cluster, and AGENTS.md:118-123 is explicit that an undestroyed TigerBeetle client is what keeps the event loop from draining — so the cleanup could stop the process exiting.

This was already in my own evidence and I read past it. A live server run in the PR description logged [TB] Reconnection attempt 1/5 immediately after answering 503 for an unreachable ledger. Nothing had asked it to reconnect. Destruction is now terminal, checked in both reconnect() and withReconnect.

Three existing tests in client.test.ts destroyed a client purely to stop its health-check interval and then called reconnect() on it — the exact contract now invalid. They keep a live client and destroy at the end instead; the interval is 30s and they advance 16s, so it never fired for them anyway. Their subjects (backoff exhaustion, dedup) are unchanged.

[P2] The new field would have broken direct callers rather than defaulting for them. createUsertrustServer and GovernorPool are exported, so a caller can pass a config that never went through ServerConfigSchema — including one written before requestTimeoutMs existed. setTimeout(fn, undefined) fires on the next tick, so every such request would have answered an instant governor_timeout. requestTimeoutOf() now applies the default at both boundaries.

Both mutation-verified by name — and both first attempts were FALSE PASSES

Recording these, because each would have shipped a test that cannot fail:

• P1: mutating one of the two destroy guards left the other one catching it, so the suite passed against deliberately broken code. Only removing both reproduces the defect — at which point the test fails by hanging to its 20s ceiling, which is the defect itself.
• P2: the test first used the instant fake governor, which wins a 1ms race, so a missing default was invisible. The governor now takes 60ms — like any real ledger round trip — and the test fails in 5ms without the fallback.

A single-layer mutation against a defense-in-depth fix is not a control. Checking that is the only reason either of these is a real test.

Gates on 7ac5b12

• vitest run — 4378 passed, 0 failed, 15 skipped
• biome check . — exit 0 (39 pre-existing warnings)
• tsc -b packages/core packages/server — exit 0
• tb-integration job re-run against real TigerBeetle 0.17.9 — 4 files, 12 tests green. Re-run specifically because this round changed shared ledger-client code (client.ts), which every governor path depends on.

A further max round on 7ac5b12 follows, since the remediation touched the shared client.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7ac5b123d8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[c-1k]

Connector review round — 2 findings, both fixed in 6b9f1e5

chatgpt-codex-connector posted two review threads on 7ac5b12. Both correct, both verified against the code before acting, both fixed and mutation-verified by name. Threads replied to and resolved.

[P1] close() could still hang. It awaits the best-effort abort of every pending hold before pool.destroyAll(), and I had bounded pool.get there while deliberately leaving the abort unbounded. So a stalled ledger did not merely fail to void a hold — it stopped teardown from ever reaching the governor destroy that would have voided it anyway. The /v1/abort route keeps its unbounded abort (a caller is waiting there, and a timeout is ambiguous on the money path); the shutdown and sweep paths have nobody waiting and already swallow errors.

[P2] destroyed was checked only on entry to reconnect(). _doReconnect sleeps up to 8s between attempts, so a destroy() landing mid-backoff was undone by the next iteration assigning a fresh native client — teardown completing while the client it tore down came back. Re-checked every iteration now.

The finding that mattered most came from #135, and it invalidated this PR's headline claim

The connector flagged on #135 that usertrust-claude-code aborts its HTTP request at 5s (hooks/lib.mjs:168). The 15s I had reasoned from is the hook process timeout in hooks.json — a different number bounding a different thing.

I chose these defaults as "below the client's 15s". With the real 5s bound, the arithmetic goes the other way:

server answers 503 at ~5.03s   client aborts at 5.00s   ->  client already gone

So the labelled ledger_unavailable this PR exists to produce would never have reached a single user — they would have gotten a generic transport error, which is only marginally better than the hang. My own PR description quoted time=5.028s as evidence the fix worked; the same number was the evidence it did not.

Chain is now monotonic with headroom, and each bound has a reason rather than a vibe:

connectTimeoutMs (3s)  <  requestTimeoutMs (4s)  <  client HTTP (5s)  <  hook process (15s)

Re-measured against a real server under the actual client bound (curl --max-time 5): HTTP=503 in 3.03s, body ledger_unavailable naming the address tried. Description updated, since it quoted the stale number.

Gates on 6b9f1e5

• vitest run — 4380 passed, 0 failed, 15 skipped
• biome check . — exit 0 (39 pre-existing warnings)
• tsc -b — exit 0
• tb-integration re-run against real TigerBeetle 0.17.9 — 4 files, 12 green (re-run because this round touched client.ts again)

Outstanding, stated plainly

The max-effort Codex CLI certification of this remediation has not run — two attempts died on an OpenAI org spend limit (Review was interrupted, EXIT=1), and a died review is indistinguishable from a clean one in the findings count, so it is recorded as unreviewed rather than clean. Last completed CLI review was max on 6a5ccb8; everything after it has been reviewed by the connector but not the CLI.

[c-1k]

Codex gate — max certification (credits recovered)

command       codex review --base origin/master
model         gpt-5.6-sol
effort        max
reviewed SHA  6b9f1e55c0f1444542af60dad2b9f1cc308ed59c
exit          0

Verdict: "Sequentially restarted deadlines can outlive the caller and temporarily strand ledger holds, while the public config change breaks existing TypeScript callers. The handshake timeout and abandoned-work cleanup also have correctness gaps."

Named the changed files throughout (server.ts ×15, client.ts ×9) — a real review, not the credit-exhausted no-op that preceded it.

Four findings, all accepted, fixed in 67d6637

Three of the four are holes in this PR's own fix, and the first reintroduces the failure the branch exists to prevent.

[P1] A per-await timeout bounds nothing a caller can observe. A cold tenant waits for governor construction and then for authorize() — two 4s timeouts are an 8s request, past the 5s at which the plugin aborts. The client is gone before its own server answers. Worse: an authorize landing in that window runs no cleanup (its own timer had not expired), so the server records a PENDING hold whose transferId nobody ever received — a stranded hold, which is the thing the previous round's onAbandoned was added to prevent. Deadline now carries one absolute budget through every await of a request.

[P1] The new config field broke TypeScript callers rather than defaulting for them — and my own test hid it. ServerConfig is the schema's inferred output and the public argument type, so a .default() makes the field required: existing object literals fail with TS2741. My test passed as ServerConfig, which is precisely how a break gets certified as working. Now .optional(), default only in requestTimeoutOf, cast removed.

[P2] connectTimeoutMs restarted for the second handshake call. A slow treasury followed by a stalled wallet ran to ~2x the setting — long enough for the server's generic deadline to fire first and replace the actionable ledger_unavailable with an opaque governor_timeout. One absolute budget across both calls, verbatim in both governors (parity test green).

[P2] A late onAbandoned that itself rejects was unobserved. The callback is typed void-returning, but an async function is assignable to it — so a cleanup failure could terminate Node. A server that dies while cleaning up after a timeout is worse than one that leaks what it was cleaning up.

Also fixed: a hint this branch turned from harmless into user-facing

LedgerUnavailableError told operators to run npx usertrust tb start. That prints "not yet implemented" (cli/tb.ts) and names port 3000 while the client defaults to 3001. Harmless while the error was unreachable — and this PR is what makes it reachable, so it is now the first thing an operator without a cluster sees. It names commands that work, and says to check what is actually holding the port.

Two of my own tests could not fail, and were replaced rather than kept

Recording these, because both would have shipped as coverage:

• A cleanup-failure test driven through the server proved nothing: the server's own callback already catches, so the guard was never exercised. Moved to Deadline unit tests, where mutation makes the run exit 1 with unhandled rejections.
• A handshake-budget test against a dead port could not distinguish shared from restarted budgets, because a dead cluster never reaches the second call. It needed a client that succeeds slowly and then stalls; under mutation it now measures 656ms against a 550ms bound.

That is three false-passing mutations across this PR. The generalisation: a passing mutation is a finding about the test at least as often as a clearance for the code.

Gates on 67d6637

• vitest run — 4388 passed, 0 failed, 15 skipped
• biome check . — exit 0 · tsc -b — exit 0
• engine-factory parity — identical in both governors
• tb-integration re-run against real TigerBeetle 0.17.9 — 4 files, 12 green

[c-1k]

Codex max certification of 67d6637 — 5 findings, fixed in 157c292

Verdict: "The handshake now fails loudly, but public config typing is broken and shutdown remains effectively unbounded. Late-timeout cleanup also corrupts provider circuit state." (EXIT=0, REVIEWED_SHA=67d6637, 2 markers, files named throughout.)

Three of the five were defects in the previous round's remediation — the only code in this PR that nobody had reviewed.

Mechanism tally: unbounded await on a ledger operation

This is the third round finding the same mechanism, each time at a site the previous fix did not cover:

round	instance	what was fixed
1	/v1/authorize hangs	the reported outage
2	close() hangs	bounded governor CONSTRUCTION in destroyAll
3	close() still hangs	governor.destroy() left unbounded — it voids pending transfers before closing the native client, so a governor built while TigerBeetle was healthy and destroyed after it died blocks in voidAllPending() forever

Three instances of one mechanism means the per-site patch was the wrong shape. The replacement was already designed and already argued for in deadline.ts — "the budget is per REQUEST, not per await, and that distinction is load-bearing" — it simply had not been applied to destroy() or the shutdown sweep. It is now.

Sweep, so this is a claim and not a hope. Every await on a governor or pool operation in packages/server/src:

$ grep -rnE "await (governor|pool)\.[a-zA-Z]+\(|await [a-z]+\.run\(|await withDeadline\(" packages/server/src/*.ts

9 bounded call sites. 3 raw awaits, each deliberate and documented:

• server.ts:240 governor.settle — unbounded on purpose: a timed-out settle has an unknown outcome on the money path, and reporting it as failed invites a double-settle.
• server.ts:278 governor.abort on the /v1/abort route — same reason; a caller is waiting to be told the outcome.
• server.ts:494 pool.destroyAll() — bounded transitively; every await inside it now carries a budget.

The other findings

[P1] The shutdown sweep took N × requestTimeoutMs. abortEntry created its deadline internally while close() awaits entries sequentially. The comment I wrote in that exact function says a per-await bound would do this — the prose predicted the defect and was read past by its own author. One budget for the whole sweep now, and the comment is a test: sweeps N stalled holds within ONE budget, which measures 1208ms (4 × 300ms) under mutation against a 900ms bound.

[P1] TrustConfig["tigerbeetle"] required connectTimeoutMs — TS2741 for any consumer passing { addresses, clusterId }. The identical break the previous round caught on requestTimeoutMs, in the package I did not re-check after fixing the first one. Optional now, default in DEFAULT_TB_CONNECT_TIMEOUT_MS.

[P2] The server README still named npx usertrust tb start — the third copy of a command that prints "not yet implemented". Two were fixed last round; this one was left. All three now name commands that work (grep -c across the plugin README, errors.ts, and this README: the only remaining occurrences are deliberate negations telling you not to use it).

Known residual — deliberately not fixed here

[P2] Reclaiming a late authorization records a provider failure that never happened. When /v1/authorize times out and authorize() lands afterwards, the server voids the unreachable hold via Governor.abort() — the only void path the interface exposes — which unconditionally calls recordFailure() and appends llm_call_failed. No provider call was ever made. Five such timeouts open the provider circuit and start rejecting healthy requests, and the audit chain carries a call-failure record for a call that did not happen. The cleanup degrades the system it is cleaning up.

The correct fix is a neutral void: release the hold without provider-failure accounting. That means new Governor API and a decision about which audit event truthfully describes "hold released, no call attempted" — frozen-format territory that deserves a designed answer, not one invented alongside an outage fix at 1am. Seen and deferred, not missed. Written up under "Known residual" in the server README so a reader six weeks from now finds it where the behaviour lives.

Gates on 157c292

• vitest run — 4390 passed, 0 failed, 15 skipped
• biome check . — exit 0 · tsc -b — exit 0
• engine-factory parity — identical in both governors
• tb-integration against real TigerBeetle 0.17.9 — 4 files, 12 green

Round-4 certification running on 157c292.

[c-1k]

Codex max certification of df1442b — 2 findings, BOTH OPEN. This PR is not certified.

Verdict: "The new deadline paths can leave an eager TigerBeetle operation unobserved and can misclassify late rejections, undermining the intended bounded-failure behavior." (EXIT=0, REVIEWED_SHA=df1442b, 2 markers.)

Recording these as open rather than fixing them, under the fleet's remediation ladder: this is the third round in which the same mechanism survived a restatement, which is the signal that the restatement is at the wrong level rather than that one more site needs patching.

The mechanism

round	site	fix applied
r5	Deadline.run entry	check the clock before racing
r6	Deadline.run exit, and the core handshake	"the clock decides on the way out too"
r7	the work starts BEFORE the check, and a late rejection skips it	open

Diagnosis: the helpers take a Promise, so the work has already started before they are called. withConnectDeadline("createTreasury", tbClient.createTreasury()) evaluates its argument eagerly — the ledger request is issued, then the guard runs. So every "check the clock first" fix could only ever check the clock after the thing it was meant to gate. The guard then throws while that live promise runs unobserved, and destroying the client rejects it into nothing: an unhandled rejection that can terminate Node 22.

The replacement (not applied here): take a thunk, not a promise. run(what, () => op), started after the check. The class then stops being expressible. The second finding — a late rejection wins the race, jumps through finally, skips the post-race clock check, so /v1/authorize can return a late 403/500 or even a 200 shadow denial instead of 503 governor_timeout — lives in the same helper and belongs in the same pass.

Constraints for whoever picks it up: both governors are pinned byte-identical by engine-factory-parity.test.ts, so the edit must be verbatim in both. Three existing tests must stay green — "refuses an already-fulfilled op when the budget is already spent", "refuses a value that WINS the race but arrives after the budget", "bounds the whole handshake, not each ledger call separately" — and the new one to add is "work is never started once the budget is spent", asserting the ledger call was never issued, not merely that it timed out.

Everything from rounds 1-6 is fixed and green

• vitest run — 4395 passed, 0 failed, 15 skipped
• biome check . — exit 0 · tsc -b — exit 0 · engine-factory parity — identical
• tb-integration against real TigerBeetle 0.17.9 — 4 files, 12 green
• cold-CI simulation (rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo, then the full suite) — green

Findings by round: 2 → 4 → 5 → 2 → 2 → 3 → 2 open.

Known residuals on this branch, both deliberate

1. The clock-vs-race mechanism above — diagnosed, replacement identified, not applied.
2. Reclaiming a late authorization records a provider failure that never happened — Governor.abort() is the only void path and unconditionally calls recordFailure() plus an llm_call_failed audit event, though no provider call was made. Five such timeouts open the provider circuit. The fix needs new Governor API and a decision about which audit event truthfully describes "hold released, no call attempted" — frozen-format territory. Written up under "Known residual" in the server README.

Neither is hidden, and neither should be read as covered by this PR's green gates.

[c-1k]

Handover detail for the two open findings (addendum to the comment above)

Exact sites, as of df1442b:

what	where
eager op — treasury	packages/core/src/headless.ts:706 · packages/core/src/govern.ts:3678
eager op — funded wallet	packages/core/src/headless.ts:713-716 · packages/core/src/govern.ts:3685-3688
the helper that must take a thunk	withConnectDeadline, defined just above each call site in both files
late-rejection path skipping the clock check	packages/server/src/deadline.ts:117-128 (the finally clears the timer and the post-race check below is never reached on the reject path)

Constraint: packages/core/tests/harden/engine-factory-parity.test.ts compares createTBEngine in the two governors as source text (comments and blank lines stripped). The edit must be byte-identical in both or that test fails — and the fix is to copy the change across, never to relax the test.

Must stay green:

• packages/server/tests/deadline.test.ts → "refuses an already-fulfilled op when the budget is already spent"
• packages/server/tests/deadline.test.ts → "refuses a value that WINS the race but arrives after the budget"
• packages/core/tests/harden/handshake-budget.test.ts → "bounds the whole handshake, not each ledger call separately" (mocks tigerbeetle-node so the first call succeeds slowly and the second stalls — a dead port cannot reproduce this, because it never reaches the second call)

The new test, and the discriminating assertion: "work is never started once the budget is spent" must assert the ledger call was never issued — e.g. createAccountsCalls === 1 after an expired budget — not merely that the call timed out. A timeout assertion passes against today's eager code, which issues the request and then throws; only the call count distinguishes "gated" from "issued and abandoned". That distinction is the entire finding.

Also relevant to the fix: the reason the eager promise matters is not just ordering. When the entry guard throws, that live promise has no listener, and destroying the client rejects it — an unhandled rejection that can terminate Node 22. A thunk removes the unobserved promise along with the ordering bug.