Describe the issue
When the TypeScript SDK's DurableTask bidirectional stream disconnects, the durable listener waits for the reconnect interval before opening a new stream.
Requests submitted during that reconnect window are appended to the existing _requestQueue. However, _connect() replaces _requestQueue with a new empty array, so those requests are silently lost. Callers waiting for the corresponding durable operation can then hang indefinitely.
This appears to be the TypeScript equivalent of the Python SDK issue fixed in #4368.
Environment
- SDK: TypeScript v1.26.1; the same queue-reset behavior is still present on the current main branch
- Engine: Self-hosted; the issue is triggered by a DurableTask stream disconnect
Expected behavior
Requests queued while the stream is reconnecting should be transferred to the new stream after the worker registration request.
Code to Reproduce, Logs, or Screenshots
- Start a
DurableListenerClient.
- Terminate its active DurableTask stream.
- Enqueue a
waitFor request during the reconnect delay.
- Allow the listener to reconnect.
- Observe that the new stream receives
registerWorker, but never receives the waitFor request.
The failure can also surface after a transport error such as:
Received RST_STREAM with code 1
Additional context
The Python SDK preserves requests submitted during the reconnect gap by carrying the previous request queue into the new stream. Applying the same behavior to the TypeScript SDK fixes the race.
I would like to work on this issue. If accepted, please assign it to @Hsuer.
🤖 AI Disclosure
Describe the issue
When the TypeScript SDK's DurableTask bidirectional stream disconnects, the durable listener waits for the reconnect interval before opening a new stream.
Requests submitted during that reconnect window are appended to the existing
_requestQueue. However,_connect()replaces_requestQueuewith a new empty array, so those requests are silently lost. Callers waiting for the corresponding durable operation can then hang indefinitely.This appears to be the TypeScript equivalent of the Python SDK issue fixed in #4368.
Environment
Expected behavior
Requests queued while the stream is reconnecting should be transferred to the new stream after the worker registration request.
Code to Reproduce, Logs, or Screenshots
DurableListenerClient.waitForrequest during the reconnect delay.registerWorker, but never receives thewaitForrequest.The failure can also surface after a transport error such as:
Received RST_STREAM with code 1Additional context
The Python SDK preserves requests submitted during the reconnect gap by carrying the previous request queue into the new stream. Applying the same behavior to the TypeScript SDK fixes the race.
I would like to work on this issue. If accepted, please assign it to @Hsuer.
🤖 AI Disclosure
I acknowledge that an LLM was used in the creation of this Issue, in accordance with Hatchet's AI_POLICY.md.
Details: OpenAI Codex was used to compare the Python and TypeScript durable listener implementations, help diagnose the request-queue race, and draft the reproduction steps.