Issue Station
Sign In
Tools hereToolbox

dify - ✅(Solved) Fix Phoenix tracing misses loop/iteration grouping and handled node error visibility [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langgenius/dify#36387•Fetched 2026-05-20 04:00:18
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
1
Author
BlackouttaBlackoutta
Participants
BlackouttaBlackoutta
Assignees
BlackouttaBlackoutta
Timeline (top)
assigned ×1closed ×1cross-referenced ×1labeled ×1

Error Message

  1. Run a workflow with a node that fails without node-side error handling.
  2. Run a workflow with a node that fails but uses node-side error handling so the workflow can continue successfully.
  3. Open both traces in Phoenix and inspect span status and exception events. Phoenix traces should preserve the workflow execution structure and error semantics:
  • When a node fails without error handling, the error status and exception event should propagate through the failed workflow path.
  • When a node handles its own error and the workflow continues successfully, the root/workflow spans should remain OK, while the errored node span should still be marked ERROR and emit an exception event. Handled-error workflow traces also lose important node-level error visibility: the workflow can correctly remain successful, but the node that encountered the handled error needs to be visibly marked as ERROR and include an exception event.

Root Cause

Phoenix traces currently make repeated loop/iteration executions hard to inspect because body nodes are not grouped by execution index.

Fix Action

Fixed

PR fix notes

PR #36388: fix(api): add Phoenix wrapper spans and error tracing

Description (problem / solution / changelog)

Summary

Closes #36387.

  • Group repeated loop and iteration body executions under synthetic Phoenix wrapper spans such as loop[0] and iteration[0].
  • Propagate workflow-level errors to the Phoenix root span when the workflow actually fails.
  • Preserve handled node exceptions: the root/workflow spans stay OK, while the errored node span is marked ERROR and emits an exception event.

Screenshots / Trace Comparisons

iteration/loop wrapper span

workflow example

<img width="2276" height="1450" alt="image" src="https://github.com/user-attachments/assets/08eec1b1-caf0-451a-8c50-275cb1e6f439" />

traces before: no iteration/loop wrapper span, cannot tell which node belongs to which index

<img width="6320" height="15712" alt="image" src="https://github.com/user-attachments/assets/9cbc2b2e-eaf5-46b9-ad64-929e72d24bc2" />

traces after: with clear iteration/loop wrapper span, can tell which node is in which index

<img width="4554" height="16384" alt="image" src="https://github.com/user-attachments/assets/7dbb725f-bd0f-4d7f-85e0-8df34c224d50" />

Emitting Error Event

workflow example

<img width="7988" height="3556" alt="image" src="https://github.com/user-attachments/assets/cdb1ecd6-8da0-4b13-8f3b-80fee3cb1952" />

before: no error event emitted and status not updated

<img width="9840" height="5536" alt="image" src="https://github.com/user-attachments/assets/b7d850e2-8c54-45ea-869e-083e3407ceed" />

after 1: trace shows 'error' status when no error handling on the node side

<img width="9896" height="5452" alt="image" src="https://github.com/user-attachments/assets/c88723b2-a03e-4350-b60a-ff8b746d2e11" />

after 2: trace shows 'OK' status when node handles error properly, but the errored node still gets 'error' status and emit error event

<img width="10016" height="5256" alt="image" src="https://github.com/user-attachments/assets/e4b88380-b6e7-470e-ae4c-8ec0347efc13" /> ## Root Cause

The Phoenix trace provider reconstructed workflow node spans directly from node executions, so repeated loop/iteration body executions did not have a stable wrapper span for each execution index. It also treated handled node exceptions as successful node spans because Dify stores handled failures as WorkflowNodeExecutionStatus.EXCEPTION, not FAILED.

Validation

  • uv run --project api pytest api/providers/trace/trace-arize-phoenix/tests/unit_tests/arize_phoenix_trace/test_arize_phoenix_trace.py -q
  • uv run --project api ruff check api/providers/trace/trace-arize-phoenix/src/dify_trace_arize_phoenix/arize_phoenix_trace.py api/providers/trace/trace-arize-phoenix/tests/unit_tests/arize_phoenix_trace/test_arize_phoenix_trace.py
  • uv run --project api ruff format --check api/providers/trace/trace-arize-phoenix/src/dify_trace_arize_phoenix/arize_phoenix_trace.py api/providers/trace/trace-arize-phoenix/tests/unit_tests/arize_phoenix_trace/test_arize_phoenix_trace.py

Changed files

  • api/providers/trace/trace-arize-phoenix/src/dify_trace_arize_phoenix/arize_phoenix_trace.py (modified, +243/-28)
  • api/providers/trace/trace-arize-phoenix/tests/unit_tests/arize_phoenix_trace/test_arize_phoenix_trace.py (modified, +330/-1)
RAW_BUFFERClick to expand / collapse

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, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.14.x / current main branch Phoenix trace provider.

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

  1. Enable Arize/Phoenix tracing for a workflow app.
  2. Run a workflow that contains loop or iteration nodes with repeated body executions.
  3. Open the trace in Phoenix and inspect the workflow span tree.
  4. Run a workflow with a node that fails without node-side error handling.
  5. Run a workflow with a node that fails but uses node-side error handling so the workflow can continue successfully.
  6. Open both traces in Phoenix and inspect span status and exception events.

✔️ Expected Behavior

Phoenix traces should preserve the workflow execution structure and error semantics:

  • Loop and iteration body executions should be grouped by execution index so repeated body executions are easy to inspect.
  • When a node fails without error handling, the error status and exception event should propagate through the failed workflow path.
  • When a node handles its own error and the workflow continues successfully, the root/workflow spans should remain OK, while the errored node span should still be marked ERROR and emit an exception event.

❌ Actual Behavior

Phoenix traces currently make repeated loop/iteration executions hard to inspect because body nodes are not grouped by execution index.

Handled-error workflow traces also lose important node-level error visibility: the workflow can correctly remain successful, but the node that encountered the handled error needs to be visibly marked as ERROR and include an exception event.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING