A LangGraph pipeline I was reviewing last year. Token costs were running over projection, slow runs were taking about 3x the normal time. Nothing was throwing errors.
When I added a retry counter per step and ran a few slow cases through, the resolve step showed a count of 7. The config had max_retries=3.
The discrepancy came from two retry layers that had been written independently and never asked to coordinate. The step-level nodes had retry logic. The orchestrator graph had a recovery edge that re-invoked subgraphs when steps returned an error state — and that edge was triggering twice on ambiguous failure modes before the orchestrator gave up. So the actual retry count for those steps was whatever the step-level config said, plus two orchestrator re-invocations.
Once I had the counter, I could see it. Before that, I was looking at prompt quality and model selection because that's what the symptoms looked like.
The instrumentation was pretty simple: a counter object passed to every node, checked before retrying, incremented after.
