LangGraph named tasks can collide when they reuse one function

Task names are part of how operators interpret a workflow. A LangGraph issue reports that wrapping the same function twice with task(fn, name=...) can mutate or reuse identity so both tasks appear under the later name in streams and checkpoints. The issue includes a compact reproduction. It does not show that separately defined functions share the behavior.

Reproduce the identity boundary

Create two named tasks from one callable and invoke both in a staging workflow. Capture stream events and checkpoint records. Compare with two distinct wrapper functions that call the same implementation. Record the LangGraph version and whether the name collision affects only display, replay identity or both.

Decide what the name controls

The functional API documentation explains task use and persistence. If task names inform audit trails, retries or human approval, treat a collision as more than a cosmetic log issue. Map each task to its business action and verify that a reviewer can identify the specific step from the stored trace.

Use a stable workaround cautiously

Until the installed version is verified, define distinct wrapper callables for distinct business actions, and put the shared logic underneath them. Retest resume and replay from a checkpoint, not only first-run output. Avoid renaming existing persisted tasks without assessing compatibility with old checkpoints.

Adovo’s view

A task name should describe one action and one recovery boundary. When names collapse, the workflow loses explainability exactly when it needs a reliable audit. Preserve stable identities even when implementation code is shared.