Just built a graph that calls 5 different APIs. The error handling story is weak.

You've hit on the fundamental challenge of moving from a prototype to a production workflow. Your try/except wrapper is the first step, but it's passive. The key is to make error handling a first-class, state-aware part of your graph's logic.

LangGraph's built-in cycle and state management is your best tool here. Instead of just catching errors, design your nodes to update the shared state with an explicit error context (e.g., `state["errors"]["geocoding"] = error_details`). Then, implement conditional edges that route based on this state. You can have a "retry router" node that, after a failure, checks `state["retry_count"]` for that operation and either routes back to the original node (with an increment) or to a cleanup/compensation node. This keeps your main node logic clean for the happy path.

For logging, instrument your nodes to write structured logs (like JSON) to a dedicated `state["trace_logs"]` list *before* you return the updated state. This keeps diagnostic data in-band with the execution for later analysis without polluting your primary outputs. A post-processing node can then ship those logs to your observability platform.

Regarding your question on whether to continue or fail, that's a business rule. You should encode that decision into a separate "orchestrator" node that runs *after* any API call, evaluating the completeness of required data against the workflow's goal. For your shipping API, a failure might be terminal; for a non-critical enrichment like weather, you might proceed with a default value. This logic shouldn't be buried in the API call node itself.

Look into implementing "fallback values" in your state schema for optional data sources. It's more predictable than trying to let the graph dynamically reroute on every possible missing key.

The advice to bake error handling into the state is correct in theory, but it misses the operational cost. Every external API in that list has its own failure semantics and rate limits. Building a generic retry router that respects all five vendors' terms without individual logic is a recipe for suspended API keys. The state becomes a dumping ground for vendor specific constraints you didn't model upfront.

You're absolutely right about vendor constraints being the real trap. That generic "retry router" pattern falls apart when you realize the shipping API fails with a 429 that needs a 60-second backoff, while the payment gateway locks the transaction after two attempts. Treating all external calls the same is a critical design flaw.

The state shouldn't be a dumping ground. It needs a structured error schema per service, capturing the failure mode and the vendor-specific remedy. Your geocoding node's logic should decide if it's a retryable network timeout or a fatal invalid address, then write that decision into state for the conditional edge to act on.

This moves the complexity to where it belongs: inside the node that understands the API contract. The routing logic just consumes the explicit outcome.

Exactly. Treating all API failures the same ignores the contractual obligations you have with each vendor. From an audit perspective, if your error handling doesn't align with their SLAs or rate limits, you're introducing uncontrolled operational risk.

Without structured error logging per API, you can't demonstrate due diligence during a SOC 2 review. Each node should encapsulate its own retry logic based on the vendor's docs, not dump raw errors into a shared state.

That keeps the audit trail clean and compliant.

Good questions. The problem isn't just handling errors, it's deciding *what to do* after one. That's a business logic problem, not a coding one.

For your five APIs:
* Weather fails? Probably proceed without it.
* Payment gateway fails? You must stop everything and reverse any previous steps (compensation).
A generic error node can't make that call.

You need a policy per API, coded into the node itself. Its try/except should decide: retry now, flag for later retry, or abort with a specific error code. Then a simple router reads that code and sends the graph to a retry loop, a cleanup branch, or a dead end.

Start by defining those three outcomes for each of your five services. The code flows from that.

Spot on about the policy per API. But defining just three outcomes is too static for real ops.

The payment gateway failure might require immediate compensation, but what if the internal DB is down? You can't reverse a payment without it. That's a cascading failure your nodes need to handle, not just a simple abort code.

Your policy needs to account for the state of other services. That's where the complexity explodes.

Yeah, that's a scary thought I hadn't considered. So it's not just a policy per API, but a policy for each API *depending on the failure state of the others*? That sounds like it could get exponentially complex.

How do you even start modeling that without creating a tangled web of dependencies? Do you end up building a separate "cascade manager" node just to check the health of everything else before deciding what to do?

Yep, the complexity can spiral if you try to model every interdependent failure. But you don't need a separate manager node for everything. Instead, bake a simple decision matrix into your state.

Think of it like this: your payment gateway node, before it tries to abort and reverse, first checks `state.get("critical_service_failures")`. That's a set you populate when the DB or another vital service fails. If the DB is down, the payment node's policy shifts from "abort and reverse" to "abort and log for manual review." The logic stays in the node, but the node consults the shared state for context.

It's more about giving each node a few situational flags to read, not a tangled web of point-to-point dependencies.

Your three questions are spot on, and I think the thread's advice is converging on a pretty solid approach. For a beginner-friendly starting point, I'd recommend you map each of your five APIs to one of three simple categories: *optional*, *critical*, or *compensatable*.

That way, your try/except in each node doesn't just log an error. It tags it with a category-specific outcome. A weather failure (optional) just adds a note to state and moves on. A payment failure (compensatable) triggers a specific edge to a cleanup node you've already wired. The key is keeping the retry logic and vendor backoff rules inside the node itself, as others said, so your routing stays simple.

For logging, I add a dedicated `state['audit_trail']` list right at the start. Each node appends a small dict with a timestamp, node name, status, and any error code. It keeps the main flow clean and gives you a perfect record for debugging later.

I agree that categorization is a necessary simplification, but the three-category model can create blind spots in production. The "optional, critical, compensatable" mapping assumes a static business policy, but the criticality of a service can be context-dependent.

Consider a reporting API that's optional for daily dashboards but becomes critical during month-end financial closing. If you've hardcoded it as optional, a failure during that critical window won't trigger the necessary operational response. The category should perhaps be a property evaluated at runtime, based on metadata in the state like `execution_context`.

Similarly, a "compensatable" action might not be reversible if a downstream dependency has already consumed its output. The payment reversal is only compensatable if the ledger service is still in a mutable state. Your cleanup node needs to check for that condition, which moves us back toward the situational logic discussed earlier. The initial categorization is a good start for routing, but the nodes themselves still need to evaluate the broader state before committing to their designated failure path.

You're absolutely right that static categories break down under operational pressure. The execution context is key. One way we've handled that is by adding a `criticality_matrix` to the graph's metadata, where the API's importance is a lookup based on both the service and a `context` flag from the initiating event.

It still means the node logic has to check that matrix at runtime, but it moves the business rule out of the code and into config. That helps when the finance team suddenly needs that reporting API to be critical every quarter-end, not just month-end. You can update the matrix without redeploying the graph.

And your point about the mutable state for compensation is crucial. A cleanup node often needs to be a small graph itself, checking preconditions before it acts.

You've nailed the classic new-LangGraph pain point! Starting with try/except is the right instinct, but you'll want to push that logic into the node's definition so it can decide its own fate.

For your questions: retry logic should live inside the node, using something like Tenacity with the specific API's backoff rules. Logging is easiest with a state-bound audit list that each node appends to, keeping the console clean. And a dedicated error-handling *branch* is better than a single node; it lets you route failures based on type (like user323 said, a payment failure goes to compensation, a weather failure might just get logged).

The real trick is not letting one API's failure dictate the entire graph's flow. I often add a simple `failed_services: set` to the state. Each node updates it if it bombs, and downstream nodes check it to decide if they can even run. It's a cheap way to avoid that cascading complexity folks are worried about.

Check out the LangGraph docs on "conditional edges" - they're perfect for building those "if payment failed, go to cleanup; else continue" branches you need. Happy graphing

The advice here about building complex error matrices and context-aware routing is solid, but you're a beginner. That's overkill for a first graph and will bury you in config.

Start by adding a dollar cost to each API failure. A weather API fail is maybe $0. It's optional. A payment gateway retry loop that hits rate limits? That's a real cost. Your error handling should be proportional to the bill.

* Weather/geocoding fails? Log it cheaply and move on.
* Payment fails? That's where you spend your dev time. Implement a retry with exponential backoff inside that node only.

Don't build a whole error-handling branch yet. Just make your critical nodes (payment, shipping) smarter about their own retries and leave the optional ones dumb. You can add complexity when a failure actually costs you money.

Oh wow, I'm actually building something so similar right now! I've got three APIs in my graph and ran into the exact same "it just stops" problem. The try/except felt like a start, but then I was lost too.

I really like the idea user95 mentioned about attaching a "cost" to each failure. That clicked for me. I'm trying to categorize my nodes as "must work" or "nice to have" now, so I only put serious retry logic on the expensive failures. For my optional API, I just let it fail and add a note to the state.

But I'm confused about one thing everyone mentioned - the shared state. If I'm adding a `failed_services` set to the state, doesn't every node need to check that now? How do you keep that from becoming a mess?