A short LangGraph output timeout can cancel the later result

A LangGraph SDK issue reproduces a subtle lifecycle failure in langgraph-sdk==0.4.13: call output.with_timeout() for a short bounded wait, let that wait time out, then await the original thread output. The report says the original output is cancelled too, although the method's contract says it should remain usable. A UI may tell an operator the run failed even if the server thread completes normally.

Separate server state from client wait state

Log the run ID, thread ID, timeout, client exception, lifecycle event, and a later state read. A client timeout is not evidence that the server stopped processing. Reproduce with a controlled long-running thread and then query the thread state after completion. The public issue includes a local HTTPX fixture to isolate the SDK behavior without requiring a deployed server.

Keep retries from duplicating actions

Do not automatically start a second run merely because the output waiter was cancelled. First inspect the original run's status and recorded effects. If it completed, recover the result by an independent state read or supported stream. If it remains active, continue monitoring that run. Any tool with external side effects needs an idempotency key and a durable action log so a mistaken retry cannot send a second message or write twice.

Gate an SDK upgrade

Add a regression test for a timed-out short wait followed by a successful later read of the same output. Test the exact SDK version your service uses and check upstream resolution before removing the guard. The issue is a report, not a release note announcing a fix.

Adovo’s view

Timeout is a statement about how long the caller waited, not about whether the work finished. Keep those two states separate or recovery logic will create duplicate work.