Loop and iteration tracing shows latest item under the first record

[Blackoutta]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.13.3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

1. Open a workflow that contains a loop node or an iteration node.
2. Run the workflow and open the run tracing panel while the loop or iteration is producing multiple records.
3. Expand the tracing records for the loop or iteration node. (You might need to refresh the page first for the collapsed tracing items to show)
4. Continue observing the latest in-progress tracing item as new loop / iteration records are created.

Loop node glitch screenshot:

DSL to reproduce:
loop display problem.yml

Iteration node glitch screenshot:

DSL to reproduce:
iteration display problem.yml

✔️ Expected Behavior

The newest tracing item should be displayed under the latest loop or iteration record that is currently running.

For example, if the workflow is already on Iteration 12 or Loop 12, the active tracing item should appear inside that latest record instead of staying attached to Iteration 1 or Loop 1.

❌ Actual Behavior

The latest tracing item is always displayed inside the first loop / iteration record in the tracing panel, even when execution has already advanced to a later record.

This makes the tracing view misleading because the active item visually appears to belong to the first iteration / loop entry instead of the latest one that is actually running.

[dosubot]

This looks like a legitimate bug in the frontend grouping logic for loop/iteration tracing items.

Root cause for the loop node: In addChildrenToLoopNode, the index is computed as:

const { parallel_mode_run_id, loop_index = 0 } = item.execution_metadata
const runIndex: number = (parallel_mode_run_id || loop_index) as number

The problem is that loop_index defaults to 0, so when parallel_mode_run_id is undefined/falsy the expression (undefined || 0) evaluates to 0. This means any in-progress child node whose loop_index is 0 (or hasn't been populated yet by the backend during streaming) gets assigned to the first loop record. The same issue occurs if loop_index itself is 0 for a legitimate first-iteration node — the OR operator can't distinguish between "missing" and "actually index 0."

For the iteration node: The addChildrenToIterationNode function has a similar pattern:

const { iteration_index = 0 } = item.execution_metadata
const runIndex: number = iteration_index !== undefined ? iteration_index : index

Because iteration_index is given a default value of 0 in the destructuring, the !== undefined check on line 11 will always be true (it can never be undefined after the default is applied), so it always uses iteration_index — which defaults to 0 when the backend hasn't populated it yet during streaming. This causes the same symptom: in-progress items land under the first record.

A fix would need to avoid defaulting these indices to 0 and instead properly handle the case where the metadata hasn't arrived yet — for example, assigning in-progress items to the latest known record index rather than index 0.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.