fix(reconciler): finalize progress on interrupt, classify interrupts distinctly, surface flight-cancel rejections - #204
Conversation
Classify setup and stream interruption as aborts while preserving handoff after normal completion, and propagate standalone Flight reader cancellation failures before complete.
🦋 Changeset detectedLatest commit: bdbee09 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bdbee09f6e
ℹ️ 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".
| > => { | ||
| if (snapshot.pending.length === 0) { | ||
| return Queue.clear(progressInputs).pipe( | ||
| return Deferred.await(flightDone).pipe( |
There was a problem hiding this comment.
When the decoded root has no pending boundaries but the Flight source remains open, this unconditional Deferred.await(flightDone) prevents both stream() and dispatch() from ever emitting complete. Unlike the pending-boundary path, it does not race against sequence.remainingMs, so even a configured maxElapsedMs cannot terminate a stuck or long-lived transport; race this wait with the render deadline and tear down the Flight source on timeout.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in #214 (merged as 4daf388). The no-pending-boundaries EOF wait is now raced against the render deadline through the same waitOrDeadline helper the pending-boundary path uses, so a configured maxElapsedMs terminates a stalled Flight transport with elapsed-time-exceeded and the source reader is cancelled on teardown. Regression test drives both stream() and dispatch() against a never-closing Flight source with maxElapsedMs: 150 and asserts timely failure plus exactly one source cancel.
Summary
Fixes the three interacting reconciler findings from #172/#177 review:
Effect.onExit, so interruption during Flight setup finalizes progress exactly like failure (previouslyEffect.catchnever fired on interrupts and progress could stay pending forever).tapError+ensuringtoStream.onExit— an interrupted stream finalizes with the abort outcome instead of falling through tohandoff-required; post-complete teardown aborts still finalize as handoff per the existing contract.flightDonedeferred that the completion path awaits, so it surfaces distinctly instead of being swallowed.Test plan
pnpm typecheck,pnpm lintclean after rebase