Node statuses are keyed by workflow node id and collapse every iteration
This is what an editor looks a badge up by, so the key has to be the id the canvas holds. A node that ran many times still has one entry, with the per-iteration picture inside it.
The rule
node_statusesis keyed by the workflow node id (the id the stored workflow gives the node), never by a job identifier, a node-type identifier or an iteration-suffixed variant.- Iterations of a node produced by a loop carry the plain node id, so every iteration collapses onto one entry.
- Only nodes that produced work get a key; a node excluded from execution has no entry and reads as idle.
- Within a collapsed entry,
statusis the status of the newest job in the group, with the later job in run order winning a tie;last_executed,execution_timeandexecution_time_uscome from the most recent job that actually started, and are null when none did;errorcomes from that started job, otherwise from the newest;executionscounts only jobs that started; andstatus_countscounts every job in the group. - A job entry's
node_idcarries the same ids.
What it means
node_statuses is keyed by the same node id the stored workflow holds, never
by the id of the job record that recorded a run of it and never by the node type it
is an instance of — a key derived from either of those would resolve every
node on a workflow to the same identifier, or to none the editor recognises,
and the badge lookup would miss. A loop producing many jobs for the same
workflow node still collapses onto one entry keyed by that plain node id, with
the per-iteration detail living inside the entry rather than spread across
suffixed keys.
Within a collapsed entry, the fields do not all come from the same job.
status comes from the newest job in the group; last_executed and the
execution timing come from the most recent job that actually started,
because a job that was created later but never ran has no timing to offer;
error follows that same started job rather than the newest one, so a
never-started duplicate cannot surface a stale message; executions counts
only jobs that started; and status_counts counts every job in the group,
started or not — so a node can show one more job in its counts than it
reports executions for.
Example
A node's original job completed after starting; a second job for the same node, created sixty seconds later, is marked failed without ever starting.
{"completed": 1, "failed": 1}1status is failed, following the newer job; error is null, because the
job that actually started never failed; last_executed and the timing are
those of the job that ran.