resumable-stream

Version:** resumable-stream 2.2.12 (Node 24, client) Problem In (), the source is read with and there is no rejection handler. When the stream returned by errors, three things happen: 1. The rejected read is an unhandled promise rejection. With Node's default , this ends the process. 2. The sentinel key is only set to in the branch, so it stays for 24 h. The subscription is never removed, and listeners never receive . If the process survives, a resumer receives the chunks and then waits forever. If the process died, nobody answers on the request channel. 3. The passed to never resolves. The source is not the only way into this state. The handler itself awaits (one call for each listener and chunk) and, in the branch, for the sentinel and . If one of these rejects (for example, the Redis connection has a short failure while chunks go to a resumer), the promise from the handler rejects with no handler. The result is the same: an unhandled rejection, is not called again, and the sentinel stays . A consumer cannot guard this path by wrapping its source. After that, every sees the sentinel , publishes a request, gets no ack, and rejects with after 1 s, for the full 24 h TTL. Reproduction Suggested fix Handle the rejection of and of the handler (for example, add a to the chain). On error, do the same cleanup as on (set the sentinel to , unsubscribe from the request channel, send to the listeners, resolve ), and then call (or close it) for the stream that returns. Optionally, could resolve instead of rejecting when the ack times out, because a producer that does not answer has nothing to resume. Related #50 is about the resume side: the ack timer can finish without settling the promise. This issue is about the producer side, which leaves the orphan sentinel that #50 then waits on. #42 is about the fixed 1000 ms ack timeout. Workaround Wrap the source so that an error ends it cleanly before reads it.

Summary In (, v2.2.12) the 1000 ms ack timer callback can finish without ever settling the promise returned to the caller, so hangs forever instead of rejecting with . Where Two paths never settle: 1. Strict clock comparison. routinely fires with . When and the sentinel complete within that same millisecond (loopback Redis, in-cluster Valkey), the guard is false, and neither nor runs. The timer already guarantees the budget, so the comparison is redundant and should just be unconditional. 2. Unhandled rejection inside the async callback. The callback is and unawaited. If or rejects (Redis error, permission denied, connection lost), the rejection escapes as an unhandled rejection and, again, nothing settles. A third, smaller issue: the resumed has no algorithm, so a consumer that cancels it leaves the handler attached until another message arrives. Reproduction of (1) Node 22, simulating the two sub-millisecond awaits: Against a real Redis, seeding an orphan sentinel () with no producer and stubbing to a constant makes hang deterministically; with the fix below it rejects after ~1 s as documented. Suggested fix plus on the (hoisting / out of ). We are running this as a local patch and can send a PR if you would like one.

Version:** resumable-stream 2.2.13 (redis 6.3.0, Upstash) Problem In , the producer's read loop awaits a publish to every rejoined listener before it reads the next chunk: Once a client rejoins with , the producer reads at most one chunk per Redis round trip. The source stream is usually a tee of an AI SDK UI message stream, so backpressure slows the whole pipeline: generation, persistence, and reacting to an abort signal. With about 55 ms round trip time (a laptop talking to a regional Upstash database), a rejoined reply streamed about 350 characters in 3 seconds instead of about 2000, and a stop requested meanwhile only took effect after the buffered backlog was drained. Stale listeners (#48, #49) make this worse, because every chunk then waits on publishes to channels nobody reads anymore. Expected Reading the source does not wait for publishes to listeners. One publisher connection already keeps publishes in order, so awaiting each publish is not needed for ordering. Suggested fix Publish without awaiting and handle rejections: We apply this as a patch on 2.2.13 and are happy to open a PR.