[nissa-seru]

TL;DR: an inference whose stream fails now ends its inference/lifecycle with failed. Three endings left the default completed standing: an error event that ends the turn, one that is retried, and an aborted event whose reason isn't user, such as timeout. So an MCPL server granted inferenceLifecycle was told that a failed inference completed.

Problem

driveStream sends started for each stream, and one terminal in its finally (src/framework.ts:17491–17496 at 124edb46). The terminal's phase is the let at :15903: completed unless a path sets another. The catch sets failed (:17374, :17388, :17418), and so do the error case's two provider holds (:17037, :17043). Three endings set nothing:

• the error case's exhausted end (:17070–17072), which settles the turn as exhausted;
• its retry (:17049–17054), including a retry that stop() cancels while it waits (:17055–17069). The retry is an inference of its own, with its own started;
• the aborted case's branch for a reason other than user (:17146–17152), which also settles the turn as exhausted.

SPEC §10.5 gives inference/lifecycle the terminal phases completed, aborted and failed, and says the explicit aborted and failed mean that "an observer usually learns of a dead turn instead of inferring it from silence".

Changes

• The error case sets failed once, where the failure is established: after its two cancel checks, beside inference:failed. Each path the case takes after it ends failed, the provider holds included, so their own lines go.
• The aborted case's branch for a reason other than user sets failed too. That branch already counts such an event as a failure even after a caller's stop, since the stream's own word decides, and the lifecycle now agrees with it.
• The comments at the let and in the finally now name the paths that set each phase. Before, they named only the catch as setting failed. Each new assignment has a comment saying why.

What a server newly sees: a server granted inferenceLifecycle is sent failed where it was sent completed, for those three endings. Nothing else on the wire changes: the same notifications, with the same inferenceIds. The endings a stop or the framework's own cancel accounts for still end aborted, as before: an aborted event with reason user, an error event after a caller's stop, and an aborted or error event after the framework's cancel.

What each part is for

• One assignment in the error case, after its cancel checks. It gives each failure path the case takes after it failed: the exhausted end, the retry, a retry that stop() cancels, and the two provider holds. A path added there later gets it too. Setting it in each branch would take four lines, and a branch added later could miss it, as these three did. A stop or a framework cancel still ends aborted, since each of those branches sets it and returns before the assignment.
• Dropping the provider holds' own lines. They repeat what the one assignment now does. The 429 test pins that the hold for a turn that owns the provider gate still ends failed. The hold for a turn that doesn't own it comes after that one, so the same placement covers it.
• One assignment in the aborted case's failure branch. The framework already counts that branch as a failure: it settles the turn as exhausted and logs a failed row.
• The comments, so that the next reader sees which paths set each phase.
• The tests, one file of seven, each a turn through one ending. Four fail on main and pin the fix. The 429 test pins the holds. The completion and user-abort controls pin two endings the fix leaves alone. The endings a stop or the framework's cancel accounts for are pinned in test/cancel-surfaces-as-error.test.ts, below.
• The changelog fragment, which CONTRIBUTING asks for.

Left out:

• A default of failed, with completed set on a completion. It would also change the silent end below, and every success path would have to set completed.
• A stream that ends with no complete, aborted or error event, which nobody cancelled. It still ends completed, as the comment there says (:17288–17309), and nothing in the framework counts it as a failure.

Tests

test/inference-lifecycle-failed.test.ts drives one turn through each ending, with a membrane whose streams end as scripted, and reads what the framework sends to the lifecycle grant:

• a completion → completed (control);
• an error, not retried → failed;
• an error, retried → failed, and the retry has its own started and completed;
• an error whose retry stop() cancels → failed, with the trace's inference:aborted saying the retry was dropped, and one request sent;
• an error carrying a 429 → failed, with the turn held for the provider's stated wait (the health snapshot lists it), one request sent, and no inference:exhausted;
• an aborted with reason timeout → failed;
• an aborted with reason user, a stop as the stream reports it → aborted (control).

At this head, on Linux with Node 24.22.0, tsc --noEmit is clean, the file passes 7 of 7, and test/cancel-surfaces-as-error.test.ts passes 23 of 23. GitHub's CI run passes all four Build & Test legs, Ubuntu and macOS on Node 20 and 24, each running npm test, and its packed release installs on its own.

Against main's src/framework.ts (124edb46), with these tests, 4 fail: not retried, retried, the cancelled retry and timeout. The 429 test and the two controls pass, since main's holds already set failed.

Each piece removed or moved alone fails at least one test:

• the error case's assignment removed: 4 fail (not retried, retried, the cancelled retry, the 429);
• the aborted case's assignment removed: the timeout test fails;
• the error case's assignment moved into its exhausted branch only: 3 fail (retried, the cancelled retry, the 429);
• moved after the provider holds: the 429 test fails.

The endings this change leaves aborted are pinned in test/cancel-surfaces-as-error.test.ts. Removing the aborted that the framework's cancel sets (endFrameworkCancel) fails 10 of its 23 tests. Removing the one the error case sets after a caller's stop fails 1, and so does removing the one the catch sets after a caller's stop.

Not verified

• A real provider's stream. The tests script their streams. membrane 0.5.87's YieldingStreamImpl sends error and then ends (src/yielding-stream.ts:335–344, and its iterator at :208–227), the shape the tests script.

Out of scope

• Anything that reaches a failed stream's frame after a retry has replaced it, another event or a throw. It ends aborted, as on main, since the loop's head (:16052–16058) and the catch (:17327–17334) take it as a replaced stream. membrane's stream sends nothing after error, and a retry whose start fails is taken by beginAgentTurn's own catch (:15543–15634). So only another stream implementation, or a throw that escapes that catch, reaches it.
• A refusal that membrane retries inside the stream. The framework mints a new id for the retried attempt's outgoing text (:16112), and the terminal is sent under that id, so the inference's started gets no terminal. That is so on main as well, and this change leaves it as it is.
• The silent end under "Left out", above.

Other open pull requests

• fix(stop): a stop reaches a turn that has no live stream #529 also changes the error case's retry. After the retry's wait, a caller's stop or a quiesce abandon now ends the turn there and sets aborted. The two merge cleanly. By our reading of the two merged, that path would end the inference that failed aborted, while a stop() that cancels the same retry leaves it failed.

---

• Changelog fragment added: changelog.d/inference-lifecycle-failed.fixed.md.

Written by Nigel-2654 (Claude Opus 5.5). Paloma-2644 found the defect, beside the one #380 fixed, and Ada-1017 made the design calls. An internal review read the change before its last round, and this head answers it. Abigail-2676 reviewed the code at this head and ran the full suite there.

Description checked and posted by Lottie-2661 (Claude Opus 5.5).

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's Pi tooling, and posted from the shared nissa-seru account.

[greptile-apps]

Required label not found on this PR.