fix(langgraph): adopt a transport-created thread id instead of aborting the run

[blove]

The bridge aborts its own in-flight run, about two milliseconds after opening the stream, whenever a consumer supplies a custom transport.

Root cause

stream-manager.bridge.ts wraps onThreadId so currentThreadId stays in sync when the transport auto-creates a thread. Its own comment says so. But the wrapper is installed only on the fallback transport:

const transport = options.transport ?? new FetchStreamTransport(apiUrl, wrappedOnThreadId, …);

Supply your own transport and the bridge never learns the created id, so currentThreadId stays null. When the consumer's callback then updates the thread-id signal:

const shouldReset = hasSeenThreadId && currentThreadId !== id;   // null !== 'abc' → true
if (resetState) abortController?.abort();                        // kills the run just created

The bridge mistakes a thread-id adoption for a thread switch.

The fix

const shouldReset = currentThreadId !== null && currentThreadId !== id;

A null current thread is an adoption, because the run streaming right now is what created that thread. A known id changing to a different id, or to null, still aborts and resets exactly as before.

hasSeenThreadId is removed as genuinely subsumed: its only job was suppressing a reset on the first emission, where currentThreadId is null by construction. The one case where the two predicates differ is a transport setting the id before the first signal emission and the signal then emitting a different id — a real switch, which should reset.

How this was found

Live instrumentation, after the first diagnosis turned out to be wrong. The reported symptom was "the browser submits the first prompt twice and the duplicate races the interrupt into an HTTP 400". The timing disproved it: across four threads the two runs were 39.584, 39.571, 39.604 and 39.598 seconds apart, a 30ms spread, and they did not overlap. That is a timer, not a race.

It was the hero walkthrough's 30-second wait timing out because the approval never arrived, then its loop re-sending the first prompt into a thread holding an unanswered interrupt. The approval never arrived because the client had aborted its own stream before any event reached it. The server had run the whole thing, interrupt included, and succeeded.

The 400 was a symptom two steps downstream of this line.

Not affected

Consumers who let the bridge construct the transport, which is why the production takeover path works. Verified by driving it by hand: prompt, approval panel, Accept, resume, all clean.

Tests

A failing test first, reproducing it with MockAgentTransport and no backend: a bridge over a custom transport that creates a thread mid-stream must not abort, asserted on the stream's own AbortSignal and on the event reaching subscribers rather than on internals. Against main it fails with expected true to be false on signal.aborted. A second test pins that a genuine switch still aborts and resets. Both mutation-checked: reverting the predicate turns the first red and leaves the second green.

Also

The wrapper's comment claimed a guarantee it only delivered in one branch. It now says what the code does, and both AgentConfig.transport and AgentOptions.transport document that a custom transport must report created thread ids through onThreadId or the thread-id signal.

Verification

langgraph 405 tests green; langgraph, ag-ui and chat green together; 0 lint errors; production build passes. No public export added, so no api-docs regeneration.

For a reviewer

Anyone working around this bug — withholding the created id from the signal, or re-submitting after the abort — will now see the first run complete normally instead.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
threadplane	Ready	Preview	Sep 5, 2026 5:06am UTC

[github-actions]

Automated approval: this PR received an intelligent (AI) code review. See the review comments on this PR.

[github-actions]

Claude finished @blove's task in 0s —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude finished @blove's task in 0s —— View job

---

I'll analyze this and get back to you.

[github-actions]

Claude finished @blove's task in 0s —— View job

---

I'll analyze this and get back to you.