LangGraph Resume Skips the Downstream Node After a Conditional Router Exception: 1.2.11 Reproduction and Workaround

LangGraph Resume Skips the Downstream Node After a Conditional Router Exception: 1.2.11 Reproduction and Workaround

If a LangGraph conditional router throws an exception, be careful when resuming the graph with the same thread_id and invoke(None, config). In the behavior reproduced here, the resume call returns normally, but the router is not called again, the downstream node never runs, and the graph has no pending task.

I independently reproduced this on langgraph==1.2.11 with both InMemorySaver and SqliteSaver. The fastest way to detect it is not to check whether resume raised an exception. You need to verify the router call count, downstream-node call count, returned state, and graph.get_state(config).next. In the router-failure case, resume returns the already-persisted {"value": 1}, while sink=0 and no pending task remains.

The application-level workaround verified here is to move fallible routing work out of the conditional-edge function and into a normal LangGraph node. Store the routing decision in state, then keep the conditional router as a pure selector that only reads that state. With this topology, the failed work remains a resumable node task and both tested checkpointers recover correctly.

This is not an official LangGraph fix. As of September 11, 2026, upstream Issue #8834 remained open, and I had not verified a released framework fix for this behavior. Treat the approach below as an application-level containment pattern, not an upstream patch.

Short answer: a successful resume call does not prove the graph resumed

The difference in the experiment is clear.

When an ordinary node fails once:

first invocation:
node -> exception

resume:
node -> router -> sink

calls:
node=2
route=1
sink=1

result:
{"value": 2}

When the conditional router fails once:

first invocation:
node -> router -> exception

resume:
returns immediately

calls:
node=1
route=1
sink=0

result:
{"value": 1}

pending_after=[]

The initial router exception is visible to the caller, but when the graph is resumed, the router is never called a second time and sink never executes.

That is more dangerous than a resume that simply throws again. Application code can see:

result = graph.invoke(None, config)

return successfully and incorrectly treat the run as recovered. In reality, it may only be returning state that was persisted before the router failed.

Tested scope

The independent XBSTACK reproduction uses:

Item	Tested value
Test date	2026-09-11
LangGraph	1.2.11
langgraph-checkpoint-sqlite	3.1.1
Python	3.10.2
Checkpointers	InMemorySaver, SqliteSaver
Execution API	synchronous StateGraph.invoke()
LLM	none
Network	none
External database/API	none

The result should not automatically be generalized to every historical LangGraph release, future releases, async execution, Postgres or Redis savers, subgraphs, or every LangGraph Platform execution path. If your runtime differs, rerun the minimum fixture instead of assuming identical behavior.

Minimal reproduction

The graph is intentionally small:

START
  |
 node
  |
conditional router
  |
 sink
  |
 END

The state contains one field:

class State(TypedDict):
    value: int

The ordinary node writes a value:

def node(state):
    calls["node"] += 1
    return {"value": 1}

The router fails only on its first invocation:

def route(state):
    calls["route"] += 1

    if calls["route"] == 1:
        raise ValueError("temporary route failure")

    return "sink"

The downstream node increments the value:

def sink(state):
    calls["sink"] += 1
    return {"value": state["value"] + 1}

The first invocation:

graph.invoke({"value": 0}, config)

raises as expected:

temporary route failure

The important part is the resume:

result = graph.invoke(None, config)

A reasonable expectation would be:

resume
→ retry route
→ route returns "sink"
→ run sink
→ final value = 2

Instead, the observed result is:

node=1
route=1
sink=0
result={"value": 1}
pending_after=[]

There is no second router call.

Control case: put the temporary failure in the node

To make sure this was not simply a case where LangGraph could not recover from any failure, I moved the one-time exception into the ordinary node.

def node(state):
    calls["node"] += 1

    if calls["node"] == 1:
        raise ValueError("temporary node failure")

    return {"value": 1}

The router becomes a pure selector:

def route(state):
    calls["route"] += 1
    return "sink"

After resuming:

node=2
route=1
sink=1
result={"value": 2}

The result is the same with both tested checkpointers.

That narrows the problem considerably: a recoverable failure inside an ordinary graph node and a failure inside the conditional routing stage do not leave the same resume behavior.

Why resume can look successful while the graph is incomplete

There are two evidence levels here.

The first is the externally observable behavior reproduced by XBSTACK:

router throws
→ prior node state is present
→ resume does not retry router
→ downstream does not run
→ no pending task remains
→ invoke returns normally

That is directly reproducible.

The second comes from the source trace documented in upstream Issue #8834. The report traces the behavior through the ordering of normal state writes, branch execution, persisted error writes, and the logic used when pending writes are restored during resume. In that execution path, ordinary node writes are already available while the failed routing operation does not reappear as a normal runnable task.

This is consistent with the final state observed locally:

node result: persisted
router failure: occurred
pending work: none
downstream: not executed

This article does not provide a LangGraph runtime patch, so it deliberately does not treat one internal line of code as a final official root cause.

A safer statement is:

In the tested LangGraph 1.2.11 execution path, a conditional-router exception does not remain as a resumable pending task in the same way an ordinary node failure does.

Why this matters in production

A conditional router like this is low risk:

def route(state):
    return "approve" if state["score"] > 0.8 else "review"

It only reads existing state and chooses a branch.

Real production graphs often evolve into something more complicated:

def route(state):
    policy = load_policy_from_database()
    quota = billing_service.check_quota(state["user_id"])
    flag = feature_service.get("new_flow")

    if not quota:
        return "quota_exceeded"

    if policy.requires_review:
        return "human_review"

    return "execute"

Or the router may call a model:

def route(state):
    decision = llm.invoke(...)
    return decision.route

At that point the router is no longer just a selector. It has become a real work step with dependencies that can fail.

Possible failures include HTTP timeouts, rate limits, database connection errors, cache failures, provider outages, malformed model responses, or temporary authorization-service failures.

If a recovery monitor only checks:

resume request returned successfully

or:

graph.invoke() did not raise

it can incorrectly mark a workflow as recovered even though a downstream business step never ran.

Verified workaround: move fallible routing work into a node

The workaround I tested is a topology change.

Instead of this:

node
  |
  v
conditional router
  |
  +----> sink

use this:

node
  |
  v
router_node
  |
  v
pure selector
  |
  +----> sink

The router_node performs work that may fail:

def router_node(state):
    decision = risky_routing_logic()

    return {
        "route_decision": decision
    }

The conditional router becomes pure:

def selector(state):
    return state["route_decision"]

The graph wiring becomes:

builder.add_edge("node", "router_node")

builder.add_conditional_edges(
    "router_node",
    selector,
    {
        "sink": "sink",
    },
)

Why the workaround is recoverable

The important difference is that the failure now occurs in router_node rather than inside the conditional-edge function.

In the verified experiment, when router_node fails on its first attempt, state inspection shows:

pending_before=["router_node"]

After:

graph.invoke(None, config)

the normal node task is retried.

The final counters and state are:

node=1
router_node=2
selector=1
sink=1
value=2
route_decision="sink"
pending_after=[]

Both InMemorySaver and SqliteSaver pass this test.

Before and after

Scenario	node	fallible routing	selector	sink	Resume
ordinary node failure	2	—	1	1	recovers
conditional-router failure	1	1	—	0	downstream skipped
fallible routing moved into node	1	2	1	1	recovers

The workaround case also preserves explicit pending work:

pending_before=["router_node"]

The original router-failure case does not:

pending_before=[]

That is an important distinction for production recovery systems.

Why I do not recommend swallowing every router error

You could write:

def route(state):
    try:
        return remote_decision()
    except Exception:
        return "fallback"

That is a different strategy. It means any routing failure is safe to convert into the fallback branch.

That may be valid for a deliberately degraded workflow. It can be dangerous when the failed dependency controls authorization, payment state, fraud checks, approval policy, compliance rules, quota enforcement, or destructive actions.

The safer general rule is:

Put retryable work in nodes. Keep conditional-edge functions focused on selecting a branch from already available state.

This keeps failure semantics, checkpoint behavior, and recovery boundaries easier to reason about.

What should be moved out of a conditional router

Review routers that perform:

• HTTP or RPC calls;
• LLM calls;
• database queries;
• Redis or cache operations;
• file reads;
• external policy lookups;
• feature-flag requests;
• remote authorization checks;
• billing or quota requests;
• retryable business logic;
• side effects.

A conditional router is better suited to logic like:

def route(state):
    if state["approved"]:
        return "execute"

    if state["needs_review"]:
        return "review"

    return "reject"

In other words, let the graph produce uncertain information in nodes and let the router choose using information that is already in state.

How to test whether your graph is exposed

First, find:

add_conditional_edges(

Second, inspect the router for external dependencies such as HTTP, databases, LLMs, filesystems, or other retryable operations.

Third, inject a one-time exception into the router.

Fourth, resume with the same thread_id:

graph.invoke(None, config)

Do not stop at the return value. Also inspect:

state = graph.get_state(config)

print(state.next)
print(router_calls)
print(downstream_calls)

If you see:

resume succeeds
state.next == []
downstream_calls == 0

then you should not treat the run as successfully recovered.

Upstream fix status

As of September 11, 2026, LangGraph Issue #8834 remained open. That means it would be misleading to say that upgrading to a particular released version is the verified official fix, and the workaround in this article should not be presented as an official LangGraph recommendation.

A framework-level fix needs to make the recovery semantics explicit when a node state write succeeds but the conditional router fails. Resume should either re-execute the failed routing step and continue to its selected downstream node, or preserve an explicit unresolved failed task so that the graph cannot appear normally completed.

The most problematic result is the one reproduced here:

resume returns normally
pending=[]
downstream never executed

because application code can interpret it as success.

Production checklist

If your LangGraph application relies on checkpoint/resume, add failure-injection tests around routing. Test router timeout, router dependency failure, invalid router response, and a router that fails on the first attempt but succeeds on the second.

Do not only assert:

assert no_exception

Verify the business outcome:

assert downstream_executed
assert final_state_is_complete

Inspect pending tasks, but do not rely on next == [] alone. The original reproduction ends with no pending task even though the downstream node never ran.

Finally, remember that moving work into a node makes retry possible, which also means the node itself must be designed for safe re-execution. If it performs payments, message delivery, order creation, external writes, or destructive actions, use idempotency keys or equivalent deduplication.

This workaround fixes the resume boundary. It does not automatically make every side effect idempotent.

Final conclusion

On LangGraph 1.2.11, when an ordinary node has already written state and its conditional router then throws, resuming with the same configuration can return the persisted state without calling the router again, without running the downstream node, and without leaving a pending task.

XBSTACK reproduced this with both InMemorySaver and SqliteSaver.

The application-level workaround verified here is:

fallible routing logic
→ normal node

conditional edge
→ pure state-based selector

With that topology, the same first-attempt failure leaves:

pending_before=["router_node"]

and resume retries the node, evaluates the selector, executes the downstream node, and reaches the expected final state.

If your conditional router currently calls a database, remote API, LLM, policy service, or any other fallible dependency, run a failure-injection test before relying on checkpoint resume in production.

A successful resume call is not enough evidence that the LangGraph workflow actually resumed.

Related reading

• LangGraph Checkpointers: Memory vs SQLite vs Redis
• LangGraph Agent Error Recovery, Retry, and Timeout
• LangGraph Cancellation and Checkpoint State Loss
• LangGraph Thread and Session State Isolation
• LangGraph topic hub

Primary evidence

• LangGraph upstream Issue #8834: Resume after a conditional-router exception skips routing and returns normally
• XBSTACK independent minimal reproduction and verified workaround
• Local experiment source directory: experiments/langgraph-conditional-router-resume-repro/

Topic path / LangGraph

Continue through the production LangGraph learning path

The LangGraph hub organizes state isolation, checkpointing, human approval, retries, observability, supervisors, subgraphs and memory into one reviewable path.

Open LangGraph hub → Start with state isolation Subscribe