At a glance. A conditional router can fail visibly on the first invocation and then disappear from the work that a resumed LangGraph execution performs. In the reported configuration, resume returns normally even though the selected downstream node never ran. Hermes filed the original minimized report; two other developers subsequently reported independent reproduction. One developed a candidate framework correction, while another published an application-level containment pattern. The upstream issue remains open. [S1–S4]
What happened
The failure is not that LangGraph suppresses the initial exception. A node writes its state update, its attached conditional router raises, and the initial invocation correctly reports an error. The surprising part comes next: resuming the same thread returns the already-written state without retrying that router or executing the downstream sink node. The graph then exposes no pending tasks. [S1]
Hermes's report isolates the distinction with a control. Move the one-time failure into the ordinary node, before the state update is produced, and resume retries the node, evaluates the route and reaches the sink. The difference is therefore tied to where execution fails, rather than a generic inability to resume a failed invocation. [S1]
When it happens
The original report tested synchronous StateGraph.invoke with both InMemorySaver and SqliteSaver, using published langgraph==1.2.11 and the unmodified source revision 81bf17b23123e4ef8b9d5f49fa09a0122fc2edd1. Its environment was Python 3.12.13 on macOS ARM64, with langgraph-checkpoint==4.2.0 and langgraph-checkpoint-sqlite==3.1.1. No model, network call, custom saver or internal runtime API was needed. [S1]
The later published-package verification used Python 3.10.2, the same LangGraph version, and the same SQLite checkpointer version. These are two tested environments, not evidence that every Python version or persistence backend is affected. [S3, S4]
Reproduction and control
The primary issue supplies the complete minimized fixture. It compares a transient exception inside a normal node with a transient exception inside that node's conditional router, keeping the state transition and intended downstream work comparable. It records call counts and pending work before and after resume instead of treating a successful return as proof of completion. [S1]
| Recorded case | Calls after resume: node / route / sink | Returned value | Pending work after resume |
|---|---|---|---|
| Ordinary-node failure, memory or SQLite | 2 / 1 / 1 | 2 | None |
| Conditional-router failure, memory or SQLite | 1 / 1 / 0 | 1 | None |
These are results reported in the original issue, not fresh results generated for this document. The absence of pending work appears in both rows, but only the control row has actually reached the sink. [S1]
What we observed
A normal return and an empty pending-task list are narrower evidence than completion of the intended workflow. Here they coexist with an explicit counter showing that downstream work did not execute. That makes the control and counters central to the report: without them, the resumed state can look like an ordinary terminal result. [S1]
This does not establish production incident frequency, data loss, or the behavior of arbitrary applications. It establishes one reproducible execution discrepancy with a clearly specified expected downstream action.
Why it happens
The source trace in the original issue connects three operations. The state writer is attached before the conditional branch; the runner records the routing error alongside an ordinary state write that already exists; and the resume path reapplies ordinary writes while skipping the error marker. The reconstructed task consequently has writes, and the execution filter excludes tasks whose writes are nonempty. The router is not revisited. [S1]
The control fails before producing the ordinary write. It therefore does not acquire the same restored-write state during resume. An independent source investigation by dharaneeshexe-web reached the same mechanism. These explanations are tied to the pinned source, not a claim that all future implementations use the same classification rule. [S1, S2]
Resolution and current remediation
There is no verified upstream framework fix in this report. dharaneeshexe-web described a candidate correction and tests, but the issue remains open and the inspected discussion does not establish an accepted or released implementation. The candidate also distinguishes failed tasks from the intentional error-handler path; it should not be summarized as a blanket instruction to discard checkpoint writes. [S2]
Separately, GitHub user 1320800521, publishing through XBSTACK, verified a containment pattern: place fallible routing work in a normal router_node, persist its decision in state, and leave the conditional edge as a pure selector. In that fixture, the failed router node remains pending and can be retried; both tested savers then reach the sink. This is the independent developer's application-level contribution, not a workaround established in Hermes's original issue and not an upstream patch. [S3, S4]
Verification
The evidence has three distinct layers. Hermes's original issue records the minimized failure and control on the published package and a pinned checkout. dharaneeshexe-web independently reports reproduction on the pinned source, three new regression tests, 108 retry tests and 457 Pregel tests passing after the candidate correction, while noting unrelated timing-sensitive failures also seen without that change. XBSTACK independently records published-package verification and containment on two savers. [S1–S4]
No test count in this paragraph is a new run performed while writing this report. The original Hermes scope is synchronous execution. An async regression reported by the candidate-fix author does not broaden the original finding into comprehensive async coverage.
Consequences and follow-on work
The original issue was filed on 6 September 2026. The candidate-fix investigation appeared on 7 September. The published-package reproduction, separate repository and external article were linked on 11 September. This is documented independent follow-on engineering before upstream resolution, not adoption of a Hermes product or evidence of a production deployment. [S1–S4]
The useful next upstream outcome would be a maintainer-accepted correction with regression coverage and a mapped release. None is asserted here.
What users should do
For an application matching this configuration, treat successful resume as insufficient completion evidence. Verify the application's required downstream effects and review the independent containment pattern against the application's own retry, side-effect and state-update requirements. The pattern is a tested option for the documented fixture, not a universal drop-in remediation. [S3, S4]
Check the upstream issue before relying on this snapshot. The remaining boundaries are explicit: other savers, subgraphs, LangGraph Platform, production prevalence and a released framework fix are not established by this report.
Status, provenance and attribution
This Technical Report is revision 1.0, published on 11 September 2026. The upstream records were reread on that date: issue #8834 was open with no linked pull request. The upstream test suites were not rerun for this report, and reported test results remain attributed to their original authors.
Prepared through Hermes Labs' agentic research and engineering infrastructure under the direction of Rolando Bosch. Agents assisted with evidence synthesis and drafting; Rolando Bosch is the responsible human reviewer and approved publication. The upstream contribution records identify the relevant Hermes engineering work and its responsible human contributor. Neither an upstream merge nor a maintainer's review constitutes endorsement of this report or of Hermes's broader research.
Related
Independent reproduction and containment: XBSTACK's repository and its linked article document new external work following the original report. Credit stays with that author. [S3, S4, S5]
Conceptual connection: Hermes's "Silent AI failure mode" applies to the resumed, terminal-looking result, not the initially visible exception. "The Generative Horizon" distinguishes operation-level success evidence from completion of a user-visible task. These are conceptual connections; neither paper nor glossary is empirical validation of this LangGraph finding. [S6, S7]
Sources
- S1. Original Hermes issue, current status, fixture and pinned source trace: github.com/langchain-ai/langgraph/issues/8834
- S2. Independent source investigation and candidate correction: issue comment 5567703544
- S3. Independent published-package verification and containment: issue comment 5629176963
- S4. XBSTACK reproduction repository, README inspected for this edition: github.com/xbstack/langgraph-conditional-router-resume-repro
- S5. External article linked by its author; direct article retrieval was unavailable when this report was prepared: xbstack.com
- S6. Hermes glossary: hermes-labs.ai/glossary
- S7. The Generative Horizon, HTML research edition: hermes-labs.ai/research/the-generative-horizon