---
id: PIPE-4
family: RT-PIPE
level: core
profiles: [runtime]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/rt-pipe/pipe-4
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# PIPE-4 — Node statuses are keyed by workflow node id and collapse every iteration

*RT-PIPE (Part II) · level: core · profiles: runtime · added in 1.0*

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

> **Normative.** This is the rule.
>
> 1. `node_statuses` is 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.
>
> 2. Iterations of a node produced by a loop carry the plain node id, so every iteration collapses onto one entry.
>
> 3. Only nodes that produced work get a key; a node excluded from execution has no entry and reads as idle.
>
> 4. Within a collapsed entry, `status` is the status of the newest job in the group, with the later job in run order winning a tie; `last_executed`, `execution_time` and `execution_time_us` come from the most recent job that actually started, and are null when none did; `error` comes from that started job, otherwise from the newest; `executions` counts only jobs that started; and `status_counts` counts every job in the group.
>
> 5. A job entry's `node_id` carries the same ids.

## Related rules

- Names: PIPE-3, PIPE-7
- Referenced by: PIPE-3, PIPE-7

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.