langgraph/how-tos/node-retries/

[giscus[bot]]

langgraph/how-tos/node-retries/

Build language agents as graphs

https://langchain-ai.github.io/langgraph/how-tos/node-retries/

[michaelozery]

Thank you!
fyi there is a typo in the 3rd line: policty

[vbarda]

thanks for reporting -- fixed!

[niklasmartin]

Can I add the error message to the messages in the state? For example, if I get Pydantic Validation Error, it would be nice to add the message to the state, so the llm knows what to do better.

[muralov]

we need this feature too.

[djprawns]

What if i have a JSONDecodeError? That inherits ValueError, and would be excluded. How could I retry on such an error?

[vbarda]

you can set retry_on, see more here https://langchain-ai.github.io/langgraph/reference/types/#langgraph.types.RetryPolicy.retry_on

[djprawns]

@vbarda , but JSONDecodeError is a subclass of ValueError. That would be excluded.

[vbarda]

that's only true for the default retry_on, but if you override it you can explicitly control what's being retried.

[reach-will]

Is using time travel/forking off graph states with errors with retry policies overkill? I believe that would lead to a lot of retries, increasing load and maybe leading to more issues instead, so I would like to know what would be the recommended approach overall, given I still see rewind/time travel mentioned in the documentation quite a bit (specifically when talking about human-in-the-loop).

[antoinegar]

It seems the documentation is wrong.
It indicates that only httpx 5xx errors yield a retry:

"In addition, for exceptions from popular http request libraries such as requests and httpx it only retries on 5xx status codes."

But the implementation of the default_retry_on returns True by default.

See httpx error hierachy:

• HTTPError
  x RequestError
  • TransportError
    • TimeoutException
      · ConnectTimeout
      · ReadTimeout
      · WriteTimeout
      · PoolTimeout
    • NetworkError
      · ConnectError
      · ReadError
      · WriteError
      · CloseError
    • ProtocolError
      · LocalProtocolError
      · RemoteProtocolError
    • ProxyError
    • UnsupportedProtocol
  • DecodingError
  • TooManyRedirects
    x HTTPStatusError
• InvalidURL
• CookieConflict
• StreamError
  x StreamConsumed
  x StreamClosed
  x ResponseNotRead
  x RequestNotRead

[QuinRiva]

Is it possible to have a node with multiple retry policies? For example, when the node executes there are could be multiple error states that require different handling:

1. Resources exhausted - retry 10 times with a high back-off
2. Response content was empty or invalid - retry once immediately

Is this achievable using the retry policy, or should I just create an error handling node?

[baahujain]

If all the retry attempts fail, then the graph execution stop immediately. How can I ensure that execution moves to another node for graceful stop of the graph?

[jkhaui]

As I understand it, this is why the current RetryPolicy implementation is inherently flawed.

There must be some sort of escape hatch which delegates control of the graph to the user when retries for a node are exhausted, rather than terminating the entire graph execution. The user can then decide if/how they want to gracefully proceed.

Either the current RetryPolicy doesn't allow this behaviour to be defined at all, or the docs don't cover it.

In short, I think the only way currently to add graceful error handling is to not use RetryPolicy. Instead, we need to implement our own custom retry logic within a try/catch block of a given node.

Would be great if someone can either prove me wrong, or confirm that this is the only solution atm.

edit: btw, I'm using the JS SDK. It seems that it might be possible to use local node state within the Python SDK to track error counts internally within a node, and then have a custom handler in the node itself when the node fails on its last retry attempt: https://changelog.langchain.com/announcements/enhanced-state-management-retries-in-langgraph-python

[saireddy-tk]

After all retries have been completed, if an error still occurs, does langgraph return a specific error such as a retry error?