[Bug] Parallel iteration inflates timing metrics

[BeautyyuYanli]

Summary

Parallel iteration has two timing distortions in backend tracing:

1. child node elapsed time can be inflated because node finish events are buffered and replayed later
2. iteration_duration_map can be inflated because per-iteration duration is computed after buffered events are replayed

Reproduction

Run an iteration in parallel mode with an LLM node inside each iteration, especially when the iteration body emits buffered events or the consumer is slow.

Expected

• node-level elapsed time reflects the node's actual completion time
• iteration_duration_map reflects the iteration's actual worker runtime

Actual

• node elapsed time can include delayed replay time
• iteration_duration_map can converge toward similar values across parallel iterations because replay delay is included

[dosubot]

Thanks for the detailed report! This is a known architectural issue — the root cause is that node completion events (NodeRunSucceededEvent) only carry a start_at timestamp, not a finished_at. In parallel mode, events are buffered in a list until the iteration completes, but the persistence layer calculates elapsed_time using naive_utc_now() when the event is processed — not when the node actually finished.

Good news: PR #33216 directly addresses this by preserving each node's actual finished_at timestamp and propagating it through the event pipeline. It's currently open for review.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}