dify - 💡(How to fix) Fix Phoenix tracing retries when parent workflow tracing is disabled [1 pull requests]

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

main / 1.14.x development branch

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

Create a multi-layer nested workflow, but disable the tracing provider for the parent workflow.

✔️ Expected Behavior

Phoenix/Arize tracing should not retry indefinitely when a nested child workflow references a parent workflow that cannot publish a parent span carrier. If the parent workflow app does not use an enabled Phoenix/Arize tracing provider, the child workflow trace should fall back to a synthetic root keyed by the parent workflow run.

This follows the source-branch spec: docs/superpowers/specs/2026-05-16-phoenix-parent-trace-fallback-design.md from commit f224813e63d33f582a79f5c76e573738620f28b0.

❌ Actual Behavior

The child workflow trace contains parent_trace_context, but the parent workflow never publishes the Phoenix parent span carrier because parent app-level tracing is disabled. The Phoenix provider treats the missing Redis carrier as temporarily pending and raises PendingTraceParentContextError, causing the ops trace task to retry until the retry budget is exhausted.