Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Stream Cancellation and Partial-Result Contract

Last updated: 4 Oct 20266 min read
tutorial
IntermediateBy AITrove Editorial

A stream can end normally, fail mid-body, or be cancelled because the user left its route. Those outcomes are not interchangeable. An AbortController can stop a fetch and its body consumption, but a server may have already produced or committed work. Attach a request identity and last confirmed sequence to the client state. On retry, use a server-supported cursor or replay token rather than appending a new stream blindly. Deduplicate repeated events by stable ID, and detect gaps when sequence numbers jump. If the feed has no resumable protocol, clear partial rows or label them explicitly until a full reread succeeds.

Working case

The case 47 feed renders 29 activity items, then the connection drops before the server's final marker. The page still has useful partial data, but it cannot claim 'All activity loaded'. The retry asks from sequence 30 if the server supports that cursor; if sequence 29 is replayed, the client deduplicates it. Switching to case 62 aborts the 47 reader, invalidates its generation, and prevents a late error from replacing case 62's loading state. A transport abort does not erase accepted server mutations elsewhere in the system.

Implementation boundary

javascript
function feedOutcome(lastSequence, expectedFinalSequence, wasAborted) {
  if (wasAborted) return "cancelled";
  return lastSequence === expectedFinalSequence ? "complete" : "partial";
}
console.log(feedOutcome(29, 62, false));
// Output: partial

The helper uses a known final sequence for illustration; real feeds may use a terminal frame, total count, or server-issued cursor. A reader loop should catch AbortError separately from network and parse failures, release its reader lock, and mark only the current request generation. Preserve the last confirmed event ID for a supported resume path, but validate authorization and filter identity on the resumed request. Dedupe by event ID and check monotonic sequence; repeated IDs are not extra events. Never present a partial export or report as if it were a certified complete dataset.

Cost and boundaries

Tracking a last sequence is O(1) state, but deduping a long resumed feed may require a set of up to O(n) IDs or a bounded window when the server guarantees order. Full replay costs O(n) transfer and parsing; cursor resume reduces that cost if the server keeps a reliable replay window. Abort can save browser work and some server work, but not necessarily every already-started operation. A clear partial-state UI costs design effort and is necessary when users make decisions from the feed. Measure resume success and duplicate rates under forced disconnects.

Failure trace

A catch block handles every rejection as 'Nothing found'. A dropped connection after 29 rows now looks like an empty successful search on retry, hiding evidence. Distinguish HTTP error, body failure, parse failure, abort, and normal terminal frame. Another defect appends replayed events without ID checks; sequence 29 appears twice and a reviewer counts it as two actions. Use stable event IDs and verify a cursor belongs to the same case and filter before accepting it.

Verification

  • A truncated feed cannot display a complete status.
  • Replay does not duplicate event IDs or hide sequence gaps.
  • A late abort or failure cannot alter a later route.

Practice drill

Stream 62 ordered events and cut the connection after event 29. Verify a visible partial state and a retry action; resume with event 29 deliberately replayed and confirm one copy remains. Remove event 31 from the replay and ensure a gap is reported. Abort during a route switch and check that case 62's state is untouched. Send an unauthorized retry cursor and confirm the server denies it. Repeat without a resume feature to verify the UI performs a full reread or clears partial data honestly.

Decision note

Name normal completion, failure, and user cancellation separately; resume only from a server-defined position.

Common Mistakes

  • Calling every stream error an empty successful result.
  • Retrying by append without a cursor and deduplication plan.
  • Assuming abort reverses work already accepted by the server.

Connected lessons

Streaming and Large Data Interfaces; Incremental Response Framing and UTF-8; Stream Backpressure and Bounded Work; Large Export Download and Integrity; Fetch requests: separate HTTP failure, transport failure, and cancellation; Live Update Reconnect and Event Ordering; Request Deadlines, Retries, and Backoff.

Apply and check

Build Project: streamed case activity and export and review Web Development: streams and interaction decisions quiz.

web-tech
web-development
Storage details