Channel lifecycle v2: RPCAbortedError, core-owned outbound queue, no abortPending#3
Merged
Merged
Conversation
- Removed abortPending() functionality in favor of handling timeouts with RPCAbortedError. - Updated tests to reflect new error handling for TIMEOUT and CHANNEL errors. - Enhanced ws-channel tests to ensure proper error throwing during down states and after close. - Adjusted createFaultChannelPair to throw errors synchronously when the channel is down. - Improved session continuity tests to validate genuine client resets and re-handshakes.
…mentation and code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements the three review points from PR #2.
abortPending removed. client() now returns { api, destroy }. Migration: shared AbortController, pass its signal per call.
New RPCAbortedError extends RPCError. Invariant: class = which side of the wire the request died on, code = what killed it.
RPCAbortedError (TIMEOUT/ABORTED/SESSION) means the frame was sent and the outcome is unknown: reconcile before retrying. Plain
RPCError means it provably never left: retry freely. Went one step further than the ask: code TIMEOUT now exists only on
RPCAbortedError. A still-queued frame that runs out of time (either timer) fails as definite RPCError("CHANNEL") with the last send
error as cause, so the promise "plain = never left" holds under any config. One-line revert if you disagree.
Queues moved out of channels into the core. Channel contract: send must throw/reject when it can't deliver, no adapter queues.
wsChannel and socketChannel reworked, maxQueue removed, auto-reconnect stays. Core retries failed sends every 250ms until new
sendTimeout option (default 10s), then rejects plain RPCError("CHANNEL"). Async sends counted sent optimistically, rolled back to
the queue on rejection. destroy() splits pending by sent flag: sent gets RPCAbortedError("SESSION"), queued gets plain
RPCError("SESSION"). Bonus: stale hello is revoked from the queue after handshakeTimeout, no more late flush.
Deviation to flag: session auto-reset narrowed to RPCAbortedError("TIMEOUT") only. Plain CHANNEL no longer resets: the frame never
left, keys are fine, transport failure is not a session event.
Verification: 276/276 tests, tsc and prettier clean. Tests 4-9 pin the class split per rejection path, incl. the
timeout-beats-sendTimeout misconfig. Spec updated: spec-channel-lifecycle.md v2, spec/api.md, README (was still documenting
abortPending).