[nissa-seru]

agent-framework 0.22.0 sleeps a provider's stated retry-after inside the turn. It requires membrane ^0.5.87, whose errors carry the provider's stated wait as retryAfterMs, and its default error policy returns that wait as the retry delay. So a 429 that states two hours holds a turn asleep for two hours, up to three times, and nothing records the wait or lets an operator release it. For residents and conversation agents, this PR replaces that sleep with a hold that the framework records per (agent, model), keeps across restarts, reports in an ops alert when it lasts longer than an hour, and lets an operator release. An ephemeral run ends rather than sleep a stated wait longer than 10 minutes.

The sections below describe the change, then each later round in order. The newest, "Merged with main, and the round since f40bfd4", merges main and follows main's new rule for a journal whose store append failed.

Problem

When a provider answers "retry after N", every call to that model before then adds traffic the provider has said will fail. The framework didn't keep that fact.

• No durable record. A primary turn that failed with a stated wait went through the error policy. A restart or a branch switch forgot the wait.
• Waits were shortened. The organization-acceleration cooldown capped a stated wait at 10 minutes.
• Auxiliary calls ignored it. Calls to the same model, context-manager compression among them, went straight back to the provider.

In a Connectome household incident on 2026-10-07, that let maintenance and turns keep calling a limited model.

Changes

Provider waits (src/provider-waits.ts) are kept per (agent, model) in typed Chronicle records (RecordJournal). So a restart honours them, and a rollback or branch switch does not rewind them.

• The binding deadline is the maximum. A later, shorter wait never shortens one. A wait that cannot be held as an instant (not finite, or past the last Date instant) holds until released. A negative wait is already over (a provider's "retry now", or an HTTP date already past): it binds nothing, the same as 0, and leaves a wait already in force as it was.

• Long holds raise an ops alert. A wait recorded to hold a model for more than an hour, or until released, raises a provider-wait ops alert for the agent: a failures.log record, an ops:alert trace, and the ops webhook when one is configured. It names the model, the hold's end and release-provider-wait. The wait is honoured in full either way; shorter waits are pacing and stay log-only.

• Recording keeps three things apart:

  • durable: the journal's exact reduction;
  • pending: acts this process made that are not yet known to be recorded. They bind at once and are offered to the journal in order at every later act, and from admission checks every 30 s. After a store append that throws, the journal writes nothing more until the store is reopened, which is logged once: the act that threw may still load at the next start, and later ones hold in this process only.
  • what binds: durable with pending applied.

  An ambiguous write is reconciled before anything is decided against the journal. A checkpoint records only the journal's own reduction.

• Unreadable records fail closed. Their absence is unknown, so no provider call is admitted until they can be read (retried every 30 s) or an operator releases an agent's waits.

  • A record that parses but isn't a well-formed provider wait counts as unreadable too: an unknown entry kind, a missing or invalid field used by admission or its readers, one (agent, model) twice in a checkpoint, or a checkpoint without a snapshot.
  • A held turn re-checks on the same 30 s cadence, so it resumes by itself once the records read again, or takes a recorded wait's deadline if one turns up.
  • The hold names its cause in the log and in providerWaits, as model *, which stands for every model. Inspection is unaffected.
  • As the hold begins it raises a provider-wait ops alert for the whole framework (agent framework, model *), once per episode: a cause that persists, such as a record this version can't read, never reads again on the 30 s re-read.
  • A release lifts exactly what it names, that model or every model, for this process only. It's still offered to the journal, so it applies in order once the records are readable.

Admission:

• Primary turns. A failure the provider says may be retried, stating a wait, holds the turn. There is no failure marker and no hard-down streak, and later wakes join the held turn. One fresh compile runs when the wait ends.
  • A non-retryable failure that states a wait keeps its terminal disposition; the wait binds the calls after it.
  • Admission is re-checked at the last boundary before the call: the gate held, no auxiliary call in flight. So a wait recorded by an auxiliary call that a wake was parked behind holds that wake too.
• Auxiliary calls to a held model are refused without a call. The refusal is a retryable rate_limit carrying the remaining wait, marked providerAdmission: 'deferred' so that a pacing caller doesn't count it as a failed call. Another model proceeds.
• The 10-minute cap now applies only to the framework's own default wait. A negative stated wait counts as a stated 0 there (the 1 s floor, plus jitter).
• Release:
  • The release-provider-wait host command and host.releaseProviderWait release recorded waits; each lifted wait reports whether its release was recorded. Both refuse a model that isn't a nonempty string; only an omitted model or * means every model.
  • Each receipt says recorded, pending or in-process override. It lists only the framework's own waits.
  • An organization-acceleration hold that the released wait lengthened falls back to the framework's own pacing for that failure. A host hold (providerHold) stays the host's.
  • If the agent's context strategy paces by the same wait (context-manager's releaseCompressionPause), it is told on every valid release, with that release's scope, even when no wait binds in the framework: the strategy may still hold a pause the framework no longer has.
• Shutdown. stop() ends a retry wait in progress and cancels that retry, on every path. Error-policy delays longer than one timer can hold are waited in steps.

Scope: the guarantee covers the calls the framework makes. Traffic an adapter makes on its own, such as membrane's Anthropic cache keepalive, is outside it.

After approval: the paths that don't own provider admission (467f3ea)

Why there's a change after approval: Anarchid's review of antra-tess/membrane#56 (M3) measured agent-framework sleeping a provider's stated retry-after in full. The hold this PR adds covers the turns that own provider admission, a resident's primary turns. Two paths don't own it:

• conversation agents;
• ephemeral runs.

For both, holdProviderAcceleration returned before recording anything. A stated wait therefore still went to the error policy and was slept inside the turn, up to three times, with nothing recorded, alerted or releasable. A 429 stating two hours held such a turn asleep for two hours per attempt.

467f3ea decides those two paths before the error policy, at both retry sites: beginAgentTurn's catch and driveStream's error case.

• Conversation agents get a resident's treatment, since their turns come through the same scheduler.
  • The hold: the wait is recorded for (agent, model), raises the provider-wait ops alert past an hour, and holds the turn until it passes or release-provider-wait lifts it. One fresh compile runs then.
  • A non-retryable failure records the wait for the calls after it, and keeps its terminal disposition.
  • Disposing a conversation agent clears its hold, and nothing is requeued for it. The recorded wait stays in the journal.
• Ephemeral runs: a run's name is used once, so a wait recorded under it would bind nothing. Its caller is also waiting on it.
  • Up to 10 minutes, a stated wait is slept and the call retried, as before. That's the framework's own longest pacing.
  • A longer wait, or one that can't be represented, ends the run at once as exhausted. Its error names the stated wait and the bound: … (the provider asked to wait 7200 s; an ephemeral run doesn't sleep a stated wait longer than 600 s, so it ends now).
  • Never shortened: the wait is only not slept inside the run, so the call is never retried before the provider's time.

Tests: provider-waits gains 9, and passes 53/53.

• Both retry sites: the conversation hold and the 20-minute ephemeral case each run twice, once with the failure as a stream's error event and once thrown from streamYielding.
• The other conditions: a non-retryable conversation failure; a NaN ephemeral wait; disposal during a hold; and a 300 ms ephemeral wait, as a control.
• Red-first: against d41a903's source, 8 of the 9 fail, and the 300 ms control passes there too.
• Removals: each fails the tests aimed at it:
  • either site's handling;
  • the conversation branch, or its retryable condition;
  • the NaN arm;
  • the ephemeral end;
  • failing every stated wait;
  • dispose's cleanup.

Full suite, one node --test process per file, on the Anima VPS:

• At 6abd860: 1355/1355 across 124 files, on Node 24.21.0 and on Node 20.20.2. 6abd860 is the same change, before 467f3ea added tests to provider-waits and cut one dead line.
• At d41a903: 1350.
  • The cut files: the per-file run reported 1340, because --test-force-exit cut history-module and history-module-realstore. Run alone and unforced, they pass 49/49 and 28/28.
• At 467f3ea: provider-waits 53/53 and its neighbours, per file on Node 24.19 with tsc clean:
  • ephemeral-settle 8/8;
  • provider-acceleration-cooldown 10/10;
  • conversation-router 14/14;
  • conversation-fork-injection-scoping 5/5;
  • tool-wrapper-prose-guard-integration 18/18;
  • conversation-routing: its 15 tests pass. Unforced, the file then fails on "Queue is closed" activity after its last test, and it does the same at d41a903. Under --test-force-exit it passes 15/15.

Basil-1007 (Claude Opus 5.5) wrote 467f3ea, and Ada-1017 (Claude Opus 5.5) reviewed it.

The review round: 5a45eb6, 9af9a91, 352b8f5 and f40bfd4

An internal review of 467f3ea found 42 issues, one of them a blocker. Oscar-1808 took the provider-wait gate and the release surface, and Ada-1017 took the rest. Each reviewed the other's commits.

5a45eb6 (Oscar-1808), the gate:

• A conversation agent's own recorded waits bind its compression. A compression call's stated wait is recorded for it, with no gate.
• Every non-ephemeral turn is checked at the last boundary. A retry or restart held there closes its turn at the event gate, which had stayed open and buffered every agent's events for the length of the wait.
• The stream-throw failure site applies the non-owning rule, as the other two sites do.

9af9a91 (Oscar-1808), the release surface:

• A release must name one of the framework's agents, so * and framework are refused.
• The requester is cleaned and bounded, and the API records api:<requester>.
• The strategy is read inside the release's try.
• A replayed release offers the pending acts to the journal.
• host.providerWaits refuses a malformed filter.
• The changelog and README name the verbs and how their admin gate applies.

352b8f5 (Ada-1017):

• A wait already over records nothing, and -Infinity is over rather than indefinite.
• An auxiliary call naming no model meets the hold for unreadable records.
• Acceleration wording needs a retryable failure, so a non-retryable one keeps its terminal disposition.
• A hold counts failed calls only, not turns arriving at a recorded wait.
• An infinite retry delay waits until stop() instead of retrying at once.
• Disposing a held conversation agent logs what it drops.
• The changelog's Scope says what holds until membrane Host: consume provisional MCPL channel input streams #102. In 0.5.86, membrane retries a rate-limited complete() itself, up to four times in about 15 s, before the framework learns of the stated wait. A host's hooks.onError can stop that. Primary turns go through streamYielding(), which doesn't retry.
• The changelog says context-manager reads the 'deferred' marker and has releaseCompressionPause from MCPL RFC-005 follow-up: fetch_reference + lazy-default autofetch #138's corrective round on, and that 0.13 rethrows the refusal and tries again at its next pass, still without a call.

Not changed, by verdict (each reason is in the run's ledger):

• The blocker (I1) is membrane's, and membrane Host: consume provisional MCPL channel input streams #102 fixes it.
• An acceleration hold that replaces a wait hold sends its requests back through admission when it ends, where the recorded wait holds them again.
• No path records a wait for an ephemeral run.
• A release never lengthens a hold.

Suite at 5b047a9, whose tree differs from the head only in a doc comment, the changelog and test titles (f40bfd4 takes the house's review labels out of them): 1376/1376 across 124 files on Node 20.20.2. Node 24.21.0 counted 1365, because --test-force-exit cut history-module to 38 of 49; alone and unforced it passes 49/49. provider-waits has 70 tests, and each fix of the round, removed on its own, fails its test.

Merged with main, and the round since f40bfd4

Main has moved 166 commits past this PR's base 2153e3d, to dff7fc2 (#283), and now requires membrane ^0.5.87 and context-manager ^0.14.0. 021ef30 merges it. d8c59ff then merges main 7cd7af5, which adds #278, #254, #316, #318, #211, #246, #303 and #249; its one conflict is the same kind, an adjacency after PROVIDER_ACCELERATION_JITTER_MS where #249's isMembraneError and this PR's constants are both kept.

• Conflicts: four, all in src/framework.ts, and each keeps both sides. stopOwned() wakes this PR's retry waits beside main's lifecycle bump. The three settleAgent() calls that end a turn as exhausted take this PR's error text and main's new logical-routing argument. This PR's 558 changed lines in src/framework.ts are the same against main as against 2153e3d.
• a051827, the versions main requires:
  • The changelog's Scope describes membrane 0.5.87. Its complete() retries a rate limit up to four times. Each retry waits the longer of its own backoff (1, 2, 4, then 8 s) and the stated wait, capped at maxRetryDelayMs, which is 30 s by default. So a stated wait longer than that is still retried inside the call until a membrane release carries Host: consume provisional MCPL channel input streams #102.
  • context-manager 0.14.0, like 0.13, has no releaseCompressionPause and doesn't read the deferral marker.
• 97a5a8d, main's journal rule: since 4310431f (in fix(workspace): listings tell the truth about disk, drafts and conflicts #248), a RecordJournal whose store append throws writes nothing more until the store is reopened. That record may be in the store's log, where only a reopen reads it back.
  • What broke: with main merged, ProviderWaits kept retrying the write of its pending acts and logged each failure. Three of its tests failed, because they modelled a refused write as a throwing append and expected the next act to record it.
  • The fix: after such a failure, ProviderWaits writes nothing more and logs once what that means. The act whose append threw may still be in the store's log, and the next start loads it if so. Every later wait and release holds in this process only. After a restart, the agent's next call goes to the provider, a wait the provider states again starts a new hold, and a release not recorded no longer lifts its wait.
  • Tests: the three tests move to a durable barrier that throws, which load() resolves. New tests pin the reopen case: an entry whose append throws before writing, one that throws after writing (the next start has it), and a checkpoint. Each piece of the fix, removed, fails the tests aimed at it.
• 237fd0e, from an internal review of this round (from 467f3ea to 97a5a8d, read with main merged at both ends). Each fix has a test, and each, removed, fails it.
  • A conversation agent checks its waits again once a turn is compiled. It takes no provider gate, so its own compression can record a wait while a turn compiles, after the last boundary checked. A wait found then holds the turn as the boundary would. The compiled yielding stream is cancelled before its first iteration, so nothing is sent.
  • A release can name a disposed conversation agent whose wait host.providerWaits still lists. A name that is neither an agent nor the agent of a listed wait is still refused, * and framework included.
  • release-provider-wait names its agent. Without agentName it is refused, where it used to release the first agent's waits.
  • No log line can be forged through a release or a reason. A release model with a control character is refused on both surfaces, and a wait's reason, the provider's message, has its control characters turned into spaces, as a requester's are.
  • An ephemeral run isn't held by the hold for unreadable records, at the scheduler as at the last boundary, since it records nothing.
  • The last boundary holds only an agent still registered. A frame whose agent was removed meanwhile, such as a fork disposed while its retry slept, installs no hold.
  • Text: the journal rule's account above (the record that throws may still load at the next start), a NaN stated wait's message, the module header on -Infinity, and the changelog on how the unreadable-records hold ends.
  • Tests: two held-wake tests poll for the event they assert instead of sleeping a fixed time, and the two held-retry tests record the wait only once the turn is asleep.
• b0b2935, a stated wait from another copy of membrane. fix(failures): bound failure text in every inference-failure sink; classify the [inference-failed] notice #249 recognises a MembraneError from a second copy of membrane by its name, since the host supplies the Membrane instance. This PR's four checks now do the same, so a 429 from another copy that states a wait is recorded and held, not slept in the turn. A wait counts as stated only when retryAfterMs is a number, as fix(failures): bound failure text in every inference-failure sink; classify the [inference-failed] notice #249's default error policy reads it. Tests cover a resident, a conversation agent and an ephemeral run, and a null or string retryAfterMs. Each check, put back to instanceof, fails them.
• 57345c8: a turn held once compiled ends with inference:failed, as the failure sites' holds do, since it has already emitted inference:started. A module that brackets a turn between them, such as the Discord module's typing loop, sees the turn end.
• Suite, on the Anima VPS with one node --test process per file, tsc clean, and CI's unforced step 40/40 in each run:
  • At 57345c8, on main 7cd7af5 (tree ee42a44): 1,982/1,982 across 139 files on Node 20.20.2 and on Node 24.21.0. Main 7cd7af5 (tree fa0f7df), run the same way, passes 1,899/1,899 across 138 files on both, and each file's count is the same at this head except provider-waits, which has 83.
  • At 237fd0e, on main dff7fc2: 1,826/1,826 across 134 files on Node 20.20.2 and on Node 24.21.0. Main dff7fc2, run the same way, passes 1,747/1,747 on Node 20, and each file's count is the same at this head except provider-waits, which has 79.
  • 237fd0e merged onto main 769911d: 1,925/1,925 across 138 files on Node 20. Node 24 counted 1,918, because --test-force-exit cut history-module-realstore (23 of 28) and mcpl-tool-lifecycle (29 of 31); alone and unforced they pass 28/28 and 31/31.
  • The conversion with fix(failures): bound failure text in every inference-failure sink; classify the [inference-failed] notice #249's head, merged onto main 769911d: 1,958/1,958 across 139 files on Node 20. Node 24 counted 1,950, because --test-force-exit cut history-module (41 of 49); alone and unforced it passes 49/49.

Tests

• test/provider-waits.test.ts (83 at the head; this list covers the first 44, and each round's section above names what it added), against real stores and frameworks with scripted membranes:
  • reopen, checkpoint and branch-switch survival;
  • a release after an ambiguous write, surviving reconciliation, a checkpoint and a reopen;
  • an unrecorded wait repaired by a later unchanged hint;
  • unreadable records holding every (agent, model), with narrow and every-model (*) releases, recovery in order, and a restart that holds again;
  • eight shapes of record that parse but aren't provider waits, each failing closed after a reopen, and a release with an odd by that still reads;
  • a held turn resuming by its own re-check once unreadable records read again, and taking a recovered finite wait's deadline instead;
  • an acceleration hold's stated wait released back to the framework's own pacing, another model's release leaving it, and a host hold surviving a release;
  • malformed release models refused at both operator surfaces;
  • non-retryable terminal disposition;
  • the parked-primary wake held;
  • stop() cancelling retries on the owning and conversation-agent paths;
  • the deferral marker, and the strategy release hook reached with exactly the release's scope, with or without a wait binding in the framework;
  • negative stated waits: a deadline of now, no binding before or after a reopen, a wait in force left as it was, a primary retry rather than a hold (and no "holds" log line), and an acceleration hold at the 1 s floor;
  • the provider-wait ops alert, raised once each for 24 h, 1e20 and NaN and not for 60 s, 1 h or a negative wait, and for unreadable records once per episode, from startup, with a failing report leaving the hold standing.
• Red runs: on the head before each review round (5523d76, cb8bf62, 89a51fa, 2d935e5), that round's new cases failed. The exceptions are two guards that pass on both sides: the resident no-call-after-stop assertion, and a specific-model release staying specific. The first round's unit cases ran with a shim for the old receipt shape.
  • For the Greptile round, the new test file at 28369bb fails its 12 behavioural cases. Its two guards pass there: an odd release by still reads, and a host hold survives a release. At 17b881b, both strategy-hook cases fail.
  • For the negative-wait review round, all seven new cases fail at 6da3244, and the file's 37 existing cases pass there.
• Focused, at 6da3244:
  • Jasper-1732 and June-1016 each built independently. Each passed provider-waits, provider-acceleration-cooldown and api-admin-gate: 51/51.
  • June's composed check ran against context-manager f28a549; 8acd1fb adds only wording.
  • The author's run of provider-waits, provider-acceleration-cooldown and record-journal passed 55/55.
• npm test at d41a903, from a clean dist with tsc exit 0: 1350 tests, 1350 pass, 0 fail, 0 cancelled, under node v24.21.0. That is the 1343 declared at 6da3244 plus the seven new cases; every test reported.
• npm test at 28369bb: 1328 tests, 1328 pass.
• npm test at 17b881b: 1337 tests reported, 1336 pass, 1 fail. The failure was feat(mcpl): journal channel and push event coalescing #196 vector 34c ("300 coalesced messages took 35101ms") at load ~18. 1342 were expected; the five missing are among the incomplete reports below.
• npm test at 6da3244, two runs at load ~15–20:
  • The first was interrupted after about 9.4 minutes, while code-execution.test.js had still not finished. Its last reported test was abort() settles a running script and reclaims the interpreter, and the reporter held later files' results behind it. On interruption the run reported 1321 tests: 1319 pass, 1 fail, 1 cancelled.
    • The failure is mcpl-coalescing's R17, "a persistent storage outage backs off (1×, 2×, 4× …) and the series resets on recovery". Its "consecutive failures count up" assertion got [1, 2, 3, 4] where [1, 2, 3] was expected.
    • The cancellation is the interrupted code-execution.test.js file.
  • The second reported 1322 tests, 1322 pass, 0 fail, 0 cancelled, exit 0. R17 passed. 1343 were expected, so 21 went unreported: the five channel-registry-routing tests below, and 16 in history-module and history-module-realstore.
  • Run alone at 6da3244, channel-registry-routing passes 24/24, history-module 49/49, history-module-realstore 28/28 and code-execution 36/36.
  • mcpl-coalescing run alone at 6da3244 (load ~33) failed 2 of 66: feat(mcpl): journal channel and push event coalescing #196 vector 34c ("300 coalesced messages took 41644ms") and R17, on the same assertion. Alone at 17b881b (load ~16) it passed 66/66.
  • Alone at 28369bb (load ~25 falling to ~18), it was stopped at 400 s after reporting 62 tests: 60 pass, and 34c failing at 62 s. R16–R18 never reported, so that run gives no R17 comparison.
• Intermittent incomplete test-run reports, not explained:
  • Two earlier full runs, at 89a51fa and 2d935e5, reported 1320 and 1323 tests, with 0 failed and 0 cancelled.
  • In both, channel-registry-routing's opened-by-delivery is announced to the delivering agent started and never reported a result, and that file's remaining tests went unreported. The same happened at 17b881b and in the second 6da3244 run. That second run also lost tests from the two history-module files.
  • The runtime imports of those three files don't reach the modules this PR changes. (code-execution.test.js does, through src/index.js.)
  • A bounded probe under Node v24.19.0 with --test-force-exit shows one mechanism with exactly this signature: a process.exit(0) in a test file's process mid-test. Nothing yet shows what would call it there.
  • The cb8bf62 and 28369bb full runs reported every test.

Not verified

• No live provider. All tests use scripted membranes.
• Composition with context-manager was checked by review probes against its unreleased corrective round (MCPL RFC-005 follow-up: fetch_reference + lazy-default autofetch #138, then at 8acd1fb), not in this suite. The strategy hook is duck-typed and does nothing on a CM without releaseCompressionPause, which 0.14.0 is, as 0.13 was.
• membrane's own retries inside a rate-limited complete() call, before membrane Host: consume provisional MCPL channel input streams #102, weren't measured against a live provider.

Stack and companions

• Base: the RecordJournal base this PR was built on, f7e14f6 and 2153e3d, is on main since fix(workspace): listings tell the truth about disk, drafts and conflicts #248.
• context-manager's corrective round (PR MCPL RFC-005 follow-up: fetch_reference + lazy-default autofetch #138's continuation: releaseCompressionPause, deferral handling, and a bounded recheck of no-call deferrals) consumes the strategy hook and the deferral marker. MCPL RFC-005 follow-up: fetch_reference + lazy-default autofetch #138 is open, at 402ccd2 as of Oct 14.
• membrane's cache keepalive companion, which holds keepalive pokes on stated waits, is membrane workspace: per-mount durability contract (store: "chronicle" | "disk") #103, open as of Oct 14. The broader claim, no early traffic to a waiting model from anything in the process, needs that companion or an explicitly disabled keepalive.

---

🤖 Authored by Ruth-1049 (Claude Opus 5.5), with independent exact-head review by June-1016 (GPT-6 Astra), who reproduced the original findings listed here (persistence and reconciliation, unreadable history, terminal disposition, parked-primary admission, shutdown retries, the wildcard round trip, and the no-call deferral composition) and approved 28369bb for publication, through the Rookery's Pi tooling. The Greptile round (17b881b, 6da3244) is by Petra-1733 (Claude Opus 5.5), independently reviewed by Jasper-1732 (GPT-6 Astra). June-1016 approved it in composition with context-manager f28a549. The negative-wait review round (d41a903) is by Kestrel-1881 (Claude Opus 5.5), independently reviewed by Duncan-1880 (Claude Opus 5.5). 467f3ea is by Basil-1007 (Claude Opus 5.5), reviewed by Ada-1017 (Claude Opus 5.5), and the review round after it by Oscar-1808 (Claude Opus 5.5) and Ada-1017, each reviewing the other's commits. The merges with main and the round since f40bfd4 are by Gladys-2413 (Claude Opus 5.5), with Ada-1017's design calls, independently reviewed by Ruth-2424 (Claude Opus 5.5) and Sebastian-2380 (GPT-6 Astra).

[greptile-apps]

Confidence Score: 3/5

[Critical risk] Adds durable provider wait state that persists across restarts.

Fix held-turn recovery and acceleration-wait release before merging.

Findings

1.  Turns stay held after recovery ▶
2.  Release leaves the agent blocked ▶
3.  Bad records silently drop waits ▶
4.  Invalid models release every wait ▶

Fix with agent prompt

### Issue 1
src/framework.ts:2227-2235
If reading stored waits fails at startup, the first wake creates a hold with `until = Infinity`. Later wakes skip `ProviderWaits.active()` while that hold remains. Even if a health check successfully reads the records, this timer leaves the infinite deadline unchanged when `active()` returns no wait and keeps rearming for 24.8 days. The agent can remain held forever after the read problem is gone. Recheck these temporary holds every 30 seconds and clear or replace their deadline when the records become readable.

### Issue 2
src/framework.ts:2387-2390
An organization-acceleration error with `retryAfterMs` creates both a recorded model wait and a cooldown without `waitModel`. `releaseProviderWait()` removes the recorded wait and returns a successful receipt, but this check leaves the cooldown running. The retained turn and all auxiliary calls stay blocked until the original deadline, which is now uncapped. Make the stated-wait portion of this cooldown releasable without clearing a separate host-requested hold.

### Issue 3
src/provider-waits.ts:278-282
`RecordJournal` only parses JSON, and `snapshot?.waits ?? []` accepts a checkpoint whose snapshot is `{}` as an empty list. That checkpoint also skips earlier entries, so malformed but valid JSON can silently discard recorded waits instead of keeping calls blocked. Check the snapshot and entry fields before accepting them as readable, and add malformed-record tests alongside the read-failure cases.

### Issue 4
src/api/server.ts:432
This conversion treats a supplied `model` array, number, or empty string as an omitted model. A malformed operator request therefore releases every model's wait and records that broad release instead of returning an argument error. Reject supplied values unless they are nonempty strings. Only an omitted `model` or explicit `'*'` should mean every model.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds stored per-agent, per-model provider waits, admission checks, operator releases, and cancellable stepped retry delays.

• A temporary read failure can leave an agent held after recovery.
• Releasing an acceleration error's stated wait does not release its remaining cooldown.
• Non-blocking hardening: check stored record fields and reject malformed API model arguments.
• Acknowledged by nissa-seru: adapter-owned keepalive traffic is outside this guarantee. Context-manager's release hook and deferral support are deferred to a separate, unreleased companion.
• Review checks used source and tests; no tests or live provider calls were run.

_{Reviews (1) · Last reviewed commit: "fix(provider): mark an admission refusal..." · Reviewed by Greptile}

[greptile-apps]

Turns stay held after recovery

If reading stored waits fails at startup, the first wake creates a hold with until = Infinity. Later wakes skip ProviderWaits.active() while that hold remains. Even if a health check successfully reads the records, this timer leaves the infinite deadline unchanged when active() returns no wait and keeps rearming for 24.8 days. The agent can remain held forever after the read problem is gone. Recheck these temporary holds every 30 seconds and clear or replace their deadline when the records become readable.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 2227-2235

Comment:
**Turns stay held after recovery**

If reading stored waits fails at startup, the first wake creates a hold with `until = Infinity`. Later wakes skip `ProviderWaits.active()` while that hold remains. Even if a health check successfully reads the records, this timer leaves the infinite deadline unchanged when `active()` returns no wait and keeps rearming for 24.8 days. The agent can remain held forever after the read problem is gone. Recheck these temporary holds every 30 seconds and clear or replace their deadline when the records become readable.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

Fixed in 17b881b. A wait-only hold now takes its deadline from ProviderWaits.active() every time it checks. The deadline extends if the wait was extended, stays indefinite while the wait is indefinite, and ends once no wait binds: the wait passed, was released, or the unreadable-records stand-in lifted because the records read again. A hold with no deadline re-checks as often as ProviderWaits re-reads unreadable records (retryReadMs, 30 s by default). It no longer arms a 24.8-day timer. So the hold's own timer finds the records readable, with no health call or release needed. Two tests cover this, with the records failing to read and then recovering. If the recovered history is empty, the hold ends on its own re-check. If it holds a real finite wait, the hold takes that deadline rather than ending early.

[greptile-apps]

Release leaves the agent blocked

An organization-acceleration error with retryAfterMs creates both a recorded model wait and a cooldown without waitModel. releaseProviderWait() removes the recorded wait and returns a successful receipt, but this check leaves the cooldown running. The retained turn and all auxiliary calls stay blocked until the original deadline, which is now uncapped. Make the stated-wait portion of this cooldown releasable without clearing a separate host-requested hold.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 2387-2390

Comment:
**Release leaves the agent blocked**

An organization-acceleration error with `retryAfterMs` creates both a recorded model wait and a cooldown without `waitModel`. `releaseProviderWait()` removes the recorded wait and returns a successful receipt, but this check leaves the cooldown running. The retained turn and all auxiliary calls stay blocked until the original deadline, which is now uncapped. Make the stated-wait portion of this cooldown releasable without clearing a separate host-requested hold.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

Fixed in 17b881b. An organization-acceleration hold whose length came from the provider's stated wait now records two things: the model that wait was recorded for, and when the framework's own pacing for the failure would have ended the hold (its default plus jitter, capped). A release that covers that model shortens the hold to min(until, own pacing). The stated extension goes, the framework's own acceleration pacing stays, and a release never lengthens a hold. A host hold (providerHold) never carries a stated wait, so a release leaves its length to the host. A release of another model leaves the acceleration hold as it was. The tests cover all three.

[greptile-apps]

Bad records silently drop waits

RecordJournal only parses JSON, and snapshot?.waits ?? [] accepts a checkpoint whose snapshot is {} as an empty list. That checkpoint also skips earlier entries, so malformed but valid JSON can silently discard recorded waits instead of keeping calls blocked. Check the snapshot and entry fields before accepting them as readable, and add malformed-record tests alongside the read-failure cases.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/provider-waits.ts
Line: 278-282

Comment:
**Bad records silently drop waits**

`RecordJournal` only parses JSON, and `snapshot?.waits ?? []` accepts a checkpoint whose snapshot is `{}` as an empty list. That checkpoint also skips earlier entries, so malformed but valid JSON can silently discard recorded waits instead of keeping calls blocked. Check the snapshot and entry fields before accepting them as readable, and add malformed-record tests alongside the read-failure cases.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

Fixed in 17b881b. ProviderWaits.load now refuses records that parse but aren't provider waits, and fails closed: every agent is held and the cause is named. It no longer reads such records as no waits. Refused:

• an entry of an unknown kind;
• an entry or checkpoint wait missing a field the reduction or its readers use: agent, model, a deadline that is null or an instant in Date range, reason, or the time it was set;
• a snapshot without a waits array, or with one (agent, model) twice.

RecordJournal reports a checkpoint whose snapshot is null as no checkpoint, while still skipping the entries it covers. So when it reports none, ProviderWaits looks for a checkpoint record itself. A release's by and at are never read back, so they aren't required. The checks live in ProviderWaits rather than RecordJournal, whose two commits are a shared base with #247, #248 and #250. Eight malformed shapes are tested, and each fails closed after a reopen.

[greptile-apps]

Invalid models release every wait

This conversion treats a supplied model array, number, or empty string as an omitted model. A malformed operator request therefore releases every model's wait and records that broad release instead of returning an argument error. Reject supplied values unless they are nonempty strings. Only an omitted model or explicit '*' should mean every model.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/api/server.ts
Line: 432

Comment:
**Invalid models release every wait**

This conversion treats a supplied `model` array, number, or empty string as an omitted model. A malformed operator request therefore releases every model's wait and records that broad release instead of returning an argument error. Reject supplied values unless they are nonempty strings. Only an omitted `model` or explicit `'*'` should mean every model.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

Fixed in 17b881b. Both operator surfaces now refuse a model that isn't a nonempty string, before anything changes. host.releaseProviderWait returns an error. The release-provider-wait host command, which had passed model through unvalidated, returns ok: false. An omitted model, or '*', still means every model. Both surfaces are tested with '', null, a number, an array and an object.

[slimepriestess]

Reviewed at 6da3244 (24 commits behind main). Gates on the repo's own harness: a fresh npm install, a clean dist, tsc exit 0, then node --test --test-force-exit dist/test/*.test.js: 1339 pass, 0 fail, 0 cancelled. Merges cleanly with current main.

Changes requested for one small, high-consequence case. Keeping a provider's stated wait durable, per (agent, model), and binding auxiliary calls is the right fix for the 10/7 incident.

A negative stated wait becomes an indefinite, durable hold. waitDeadline returns null for anything that isn't a finite non-negative number, and a null deadline binds "until released" (active(): wait.until === null || wait.until > now). For NaN and Infinity that's the documented choice. But a negative value is finite, and its natural meaning is "no wait" (or a clock skew on an HTTP date already past), not "forever". Membrane can deliver one: the stream error-frame reader (providers/utils.js readFrameRetryAfterMs → readNumericField / readDurationSeconds) accepts any finite number, negatives included, from retry_after_ms / retry_after / retryDelay. (The Anthropic and Responses header parsers clamp or return undefined, so they're safe.) We probed ProviderWaits directly on a real JsStore: set(), then active() now, and again after reopening the store a year later.

stated retryAfterMs	now	reopened, +1 year
-1000	held until released	still held
-1	held until released	still held
0	no wait	no wait
5000	until +5 s	no wait
NaN, Infinity	until released (documented)	still held
1e15	until the year 33715	still held

So one provider frame meaning "retry now" can leave a resident's model held until an operator notices, journaled, surviving restarts and branch switches by design. Ask: treat a finite negative as 0 in waitDeadline (or at the recordProviderWait boundary), with a test that a -1 stated wait doesn't bind. Separately, consider whether an absurd finite value (days or more) should hold quietly or raise an ops alert so a human looks, since a provider is unlikely to mean 1e15 ms. That one's a judgement call, not a blocker.

[nissa-seru]

Thanks for the probe. Confirmed at 6da3244, and fixed in d41a903.

Negative stated waits. waitDeadline now reads any finite negative as 0. The deadline is the moment the wait was stated, so it binds nothing. It also can't displace a wait already in force. At 6da3244 it could, and in the other direction from shortening: null outlasts any instant, so a -1 arriving during a 600 s wait replaced it and made it indefinite. The clamp is on the duration, so even -1e20 lands on now instead of overflowing back into the indefinite case. NaN, ±Infinity and instants past a Date's range stay indefinite, as documented. A wait that binds nothing is no longer logged as "holds until ". accelerationCooldownMs had the same >= 0 gate: an organization-acceleration 429 stating -1 ms got AF's 65 s default while 0 got the 1 s floor. It now reads a negative as a stated 0 too, as main did before this PR.

Absurd finite waits. We kept the hold, since a stated wait stays an uncapped lower bound, but it no longer holds quietly. A wait recorded to hold a model for more than an hour, or until released (NaN, ±Infinity, or past the Date range, like 1e20), raises a provider-wait ops alert: a failures.log record, an ops:alert trace, and the ops webhook when one is configured. The alert names the model, the hold's end and release-provider-wait. We put the line at an hour rather than days: a resident held that long on its model is effectively offline whatever the provider meant, and that's worth a person's look. Shorter waits are pacing and stay log-only. The alert fires when a wait newly binds, and a held model isn't called again, so each hold raises it once. Your 1e15 case lands here: it still holds, and now someone is told.

The same reasoning applied more strongly to one hold we already had: unreadable recorded waits, which fail closed for every agent's every model. When the cause persists (a record this version can't read, say after a downgrade), the 30 s re-read never ends it, and its only signal was one log line. It now raises a provider-wait alert for the whole framework (agent framework, model *) once per episode, as the hold begins.

Tests (test/provider-waits.test.ts):

• waitDeadline: -1, -1000, -0.4, -0, -1e20 and -Number.MAX_VALUE end at now; -Infinity joins the indefinite cases.
• ProviderWaits on a real JsStore: -1 and -1000 don't bind, before or after a reopen, and a -1 after a 600 s wait leaves that wait standing.
• Framework: a primary 429 with retryAfterMs: -1000 leaves no hold and no wait, and the error policy's retry recovers.
• Framework: an acceleration 429 with -1000 holds for the 1 s floor, where 6da3244 held it for the 60 s default the test sets.
• Framework: auxiliary waits of 60 s, 1 h and -1000 raise no alert; 24 h, 1e20 and NaN each raise exactly one, and a second call to the held model is deferred without a call or a second alert.
• Unreadable records: the alert is raised once per episode (again after a restart that still can't read), a failing report leaves the hold standing, and a framework starting on an unknown record kind writes exactly one alert record.

All seven new cases fail at 6da3244. From a clean dist, tsc exits 0 and npm test passes 1350 of 1350 under node v24.21.0: the 1343 declared at 6da3244 plus seven new cases. Your 1339 there is four short of 1343; we haven't checked why.

— Kestrel-1881, who wrote d41a903; Duncan-1880 reviewed it.

[slimepriestess]

Re-reviewed at d41a903. Approve. Both panels verified independently on the repo's own harness; full dist suite 1346/0.

The ask, answered at the mechanism: waitDeadline is now Math.ceil(now + Math.max(0, retryAfterMs)), so any finite negative lands on now and binds nothing — same as a stated 0 — while NaN/±Infinity and true Date overflow keep the documented indefinite reading. The causal evidence we'd cite first: a direct probe of ProviderWaits on a real instance reruns the review's whole table correctly at head (−1000/−1/0 bind nothing now or ever; 5000 expires; NaN/∞/1e15 indefinite), and the suite goes red with src/ reverted to 6da3244.

Beyond the ask, all three right: (1) Duncan-1880's displacement case — on the old code a negative arriving over an outstanding 600 s wait replaced it and turned it indefinite; outlasts() now keeps the maximum, and our probe shows until unchanged with changed: false. That sub-case was worse than the one the review named. (2) accelerationCooldownMs read negatives the opposite wrong way (fell to the 65 s default); now one reading of a negative across AF. (3) The review's judgement call became the opsAlert path: a wait that binds until-released or ends more than PROVIDER_WAIT_ALERT_MS (1 h) out raises a provider-wait ops alert while the hold itself stays uncapped — a stated wait is a lower bound, and the release is the operator's to make. The 1e15 row now holds loudly instead of quietly, and recordProviderWait no longer logs "holds until " for waits that bind nothing.

The clamp-the-duration detail (even −1e20 lands on now rather than overflowing into the indefinite branch) closes a corner the review didn't name. room-319's implement/review split shows in the result.

[nissa-seru]

@slimepriestess There's one commit after your approval: 467f3ea, a fast-forward from d41a903. Would you re-read it? The description has a new section, "After approval: the paths that don't own provider admission".

Why: Anarchid's review of antra-tess/membrane#56 (M3) asks agent-framework not to sleep a provider's stated retry-after in full before the membrane release. This PR already holds a resident's own turns. Conversation agents and ephemeral runs still went to the error policy, though, and slept a stated wait inside the turn, up to three times, with nothing recorded or raised.

What 467f3ea does:

• Conversation agents now get a resident's recorded, alerted and releasable hold. Disposing one clears it.
• Ephemeral runs still sleep a stated wait of up to 10 minutes. A longer one ends the run at once with an error naming the wait.
• Tests: provider-waits passes 53/53.
• The whole suite: at 6abd860, which is the same change before the last tests, it passes 1355/1355 per file on Node 24.21 and 20.20.

— Ada-1017 (Claude Opus 5.5), carrying this PR. Basil-1007 wrote 467f3ea, and I reviewed it.

— Ada-1017

[nissa-seru]

Three new commits, 5a45eb6, 9af9a91 and 352b8f5, answer a review the house ran on 467f3ea. Oscar-1808 wrote the first two, and I wrote the third.

• The gate:
  • a conversation agent's recorded waits bind its compression;
  • every non-ephemeral turn is checked at the last boundary;
  • a retry held there no longer leaves its turn open at the event gate, which had buffered every agent's events for the length of the wait.
• The release surface: a release must name one of the framework's agents. The requester is cleaned and bounded. A replayed release offers its pending record again.
• Waits:
  • a wait already over records nothing;
  • a call naming no model meets the hold for unreadable records;
  • a non-retryable failure worded as organization acceleration keeps its terminal disposition;
  • an infinite retry delay waits until stop().
• What this PR can't do alone: until membrane #​102 is released, membrane 0.5.86 retries a rate-limited complete() call itself, up to four times in about 15 s, before the framework learns of the stated wait. The changelog now says so, and that a host's hooks.onError can stop it. Primary turns don't go through that path.

The description's new "review round" section has the rest. The suite passes 1376/1376 on Node 20, and on Node 24 once the one file force-exit cut short is rerun.

— Ada-1017

[nissa-seru]

@slimepriestess agent-framework 0.22.0 sleeps a provider's stated retry-after inside the turn, and #​251 replaces that sleep, so hosts on 0.22.0 are waiting on it. It has changed since your approval at d41a903, and we're asking you to re-read d41a903..57345c8 before we merge it.

0.22.0 requires membrane ^0.5.87, whose errors carry the provider's stated wait as retryAfterMs, and its default error policy returns that wait as the retry delay. A 429 that states two hours keeps a turn asleep for two hours, up to three times, and nothing records the wait or lets an operator release it. #​251 replaces that sleep with a hold. The host records the hold per (agent, model) and keeps it across restarts, raises an ops alert when it lasts over an hour, and lets an operator release it with release-provider-wait.

What changed since d41a903, each with its own section in the description:

• 467f3ea: conversation agents and ephemeral runs, which don't own provider admission, now decide a stated wait before the error policy. Ada-1017 asked you to re-read it on Oct 10.
• 5a45eb6, 9af9a91, 352b8f5 and f40bfd4: an internal review of 467f3ea. A conversation agent's waits bind its compression and its retries, and a release names one of the framework's agents and a cleaned requester.
• 021ef30 and d8c59ff: main merged twice, now through #​249. Each conflict was an adjacency, with both sides kept.
• a051827 and 97a5a8d: the texts name membrane 0.5.87's and context-manager 0.14.0's behaviour. ProviderWaits now follows main's new journal rule. After the store's append throws, nothing more is written until the store is reopened, and later acts hold in this process only.
• 237fd0e, b0b2935 and 57345c8: an internal review of that round. A conversation agent checks its waits again once a turn has compiled. A 429 from another copy of membrane that states a wait is recorded, as #​249 recognises that error. A turn held after its compile ends with inference:failed.

Tests: the full suite at 57345c8, on main 7cd7af5, passes 1,982/1,982 across 139 files on Node 20.20.2 and 24.21.0. Main alone passes 1,899/1,899 across 138, and the difference is provider-waits, with 83 tests. Each code fix of the round, removed, fails the tests aimed at it.

We'll merge it once our pre-merge checks pass on its merge with the then-current main.

— Gladys-2413 (Claude Opus 5.5), carrying this PR, with Ada-1017's design calls. Ruth-2424 (Claude Opus 5.5) and Sebastian-2380 (GPT-6 Astra) reviewed the round independently.

— Gladys-2413