Skip to main content

Error Management

An error in a workflow is not a failure in itself: it is a signal. This guide describes the complete incident management lifecycle in Ecosystem — anticipate failures, capture errors, analyze the causes, and resolve incidents — so no failed execution goes without an exploitable trace.

The lifecycle of an error​

PhaseGoalEcosystem component
AnticipatePrevent the propagation of corrupted dataExtractors, Condition node
CaptureCentralize the failure logicOn Error node, Stop on failure option
AnalyzeUnderstand the exact state at the moment of the errorTraces
ResolveRestart cleanly after the fixTrace replay

1. Anticipate (prevention)​

Validate API responses with extractors​

Systematically use extractors (JSONPath) in your HTTP(S) Request nodes. If critical data is missing from the response, the node fails immediately instead of propagating corrupted data to the following nodes.

The HTTP node injects its response into context.lastResponse:

{
  "lastResponse": {
    "status": 201,
    "success": true,
    "headers": {
      "content-type": "application/json",
      "ratelimit-remaining": "49"
    },
    "data": {
      "id": "12345",
      "status": "created"
    }
  },
  "orderId": "12345"
}

In this example, a JSONPath extractor $.data.id copied the identifier into context.orderId. Without this value, the node fails — and the failure is then handled by the On Error node.

Check business content with a Condition node​

An API can respond 200 OK while returning invalid business content (empty list, missing field, unexpected value). After each HTTP request, place a Condition node that checks the state of the response:

{{lastResponse.success}} === true && {{lastResponse.data.items.length}} > 0
  • True branch: processing continues
  • False branch: switches to dedicated logic (alert, fallback, On Error node)

2. Capture (reaction)​

The On Error node, an overall safety net​

The On Error node is the safety net of your workflow: it centralizes the failure logic (alert by email, log to an external system, rollback) as soon as a node of the workflow fails. It is a starting point: you cannot connect to it, it triggers automatically on an error.

It receives the error information from the failing node:

{
  "error": {
    "message": "HTTP 503 Service Unavailable",
    "code": "HTTP_ERROR",
    "details": {}
  },
  "node": "Get_Customer_Profile",
  "lastResponse": {
    "status": 503,
    "success": false
  }
}

The "Stop execution on failure" option​

On each node, the Stop workflow execution on failure option decides whether an error stops the whole workflow or whether the execution continues:

ValueBehaviorRecommended use
true (default)The workflow stops immediately — or forwards the error to the connected On Error nodeCritical steps: payment, stock update, database write
falseThe workflow continues; the error remains available in lastResponseNon-blocking steps: optional enrichment, logging

3. Analyze (debugging)​

Reading a trace​

The execution trace is the source of truth for debugging: it contains the exact state of the context and data at the moment of the error, node by node. In the event of an incident, always start from the failing node, check its error message, then go back up the workflow.

Anonymization vs visibility​

By default, Ecosystem hides certain sensitive data in traces. If you need to see the details of a complex technical error, check the anonymization settings of the node concerned (Anonymize option): disable it only if necessary and temporarily.

GDPR caution

Never deanonymize personal data (PII): a non-anonymized trace contains the raw data details. To diagnose, prefer a test execution or a replay in Complete mode on non-sensitive data.

4. Resolve (remediation)​

Replaying a trace​

From the trace history, you can rerun a failed execution after fixing a configuration or waiting for a third-party service to come back online:

  1. Open the failed trace
  2. Fix the workflow or the input data
  3. Click Rerun the workflow — the replay also lets you choose a different tracing mode for a complete diagnosis
  4. Check the new execution in the history

Checklist​

Before going to production
  • Every HTTP call has an extractor on the critical data
  • A condition checks lastResponse.success after each request
  • An On Error node centralizes the failure alerts
  • Critical steps have the Stop on failure option enabled
  • Nodes handling PII remain anonymized

Next steps​