mirror of
https://github.com/n8n-io/n8n.git
synced 2026-10-21 20:20:03 +02:00
7875da9870
Six prior runs, four of them failed on the same node, and the most recent one succeeded. The user asks why the workflow has been flaky all week, so the answer is only visible by inspecting more than the newest record. Written expecting a failure, on the theory that the agent samples the head of the execution list. The theory was wrong: 6/6 in both iterations. It lists all six executions, then debugs two of the non-latest error runs, and never settles for the successful newest one. Five tool calls. Kept, with the description rewritten to say what it actually measures. Multi-record aggregation is a capability the agent already has, so this is a regression guard rather than a baseline: a context change that surfaces only the latest run, or compresses history away, shows up here as a drop from 6/6. At quality ceiling the second axis is spend, and the tool-call and token totals recorded here are what a cheaper approach has to beat without losing the pattern. The assertion stays precise about the mechanism. `failedNode` cannot appear if only the latest execution was debugged, because the latest execution did not fail. |
||
|---|---|---|
| .. | ||
| agents | ||
| discovery | ||
| subagent | ||
| workflows | ||
| source.ts | ||