Skip to main content
The Errors tab in the Flow Editor UI gives you a single place to see why your pipeline failed and a one-click on-ramp to ask the AI to propose an IR change that handles the failure pattern.

​
What it surfaces

For the latest failed (or completed_with_errors) run:
  1. Failure summary — failed node id + the error message + run id + timestamp.
  2. DLQ row sample — when the failed node is a validate node with quarantine.table configured, the top 10 rows from that quarantine table for this run, with the rule id that caught each row.
  3. Fix-with-AI button — composes a structured prompt: 
    The latest run of pipeline <id> failed.
Failed node: <nodeId>
Error: <message>
Sample failed rows (top 5):
  - {...}  // failed rule: rule-a
…
Propose an IR change that handles this error pattern …
    Then opens the AI Panel with the prompt prefilled in the input.

​
API

GET /api/v1/pipeline-runs/:id/dlq?node=<validateNodeId>&limit=50
Tenant scoping: the run must belong to the current tenant. IR resolution: the route looks up the IR version via pipeline_runs.metadata.irVersion, finds the named validate node, and queries its configured quarantine.table filtered by runId + nodeId. Response shape: 
{
  "runId": "...",
  "nodeId": "v",
  "quarantineTable": "dlq.orders",
  "count": 5,
  "rows": [
    { "id": 1, "ruleId": "rule-a", "row": {...}, "createdAt": "..." }
  ]
}
Honest residuals (200 with residual message, never silent failure):
  • Validate node has no quarantine.table configured → “failed rows are not persisted for this node”
  • Quarantine table doesn’t exist yet → “no rows ever failed for this node”

​
What’s not in 6.3

  • Selective replay-from-DLQ runtime (the replayDlqOnly flag on POST /pipelines/:id/run): Phase 6.6 hardening. The Errors tab does NOT ship a fake button that does nothing.
  • DLQ for non-validate failures (source format errors land in .failed/ folder, not the DLQ table): Wave 4 polish.