GitHub Repo
Langflow Community Reports Phoenix Tracing Isolation Bug That May Route Concurrent Workflow Records to the Same Project
A community reproduction on October 5 using Langflow 1.12.4 indicates that concurrent workflows running in the same process may send LangChain trace records to the first Phoenix project. The report includes a minimal reproduction and output comparison, but maintainers have not confirmed the issue and no fix has been merged.

On October 5, the Langflow GitHub community reported a concurrency issue with Phoenix tracing: when two workflows run interleaved in the same process, LangChain tool and chain execution records may be sent to the first project, even when different project names are configured. The reporter used an unmodified Langflow 1.12.4 package and provided a minimal reproduction comparing sequential and concurrent execution. The issue remains open, and the page lists no fix branch or pull request. Community report
The report points to the lifecycle of ArizePhoenixTracer as the cause: each workflow calls the process-wide LangChainInstrumentor.instrument() with its own tracer provider, then calls uninstrument() when it finishes. According to the case analysis, the second instrumentation does not establish an independent provider, so both workflows share the first project's exporter. When either workflow ends, it may also remove tracing instrumentation that the other is still using. Mechanism analysis
The reproduction uses an in-memory span exporter and attaches distinct metadata markers to the two workflows. With sequential execution, each project receives its own TOOL and CHAIN records. With concurrent execution, both sets of markers appear in the first project, while the second has no corresponding records. This supports the report of incorrect project attribution, but the test did not use a real remote Phoenix collector and does not show that model outputs or tool results are affected. Reproduction and limitations
The technical risk is the reliability of observability data. Phoenix’s official documentation uses project_name to specify which project records belong to, while Langflow’s documentation says its integration collects LangChain and component traces and can add spans to datasets. If project attribution is confused, engineers could misidentify which workflow produced latency or errors, and later evaluation data could include samples from other workflows. This impact is inferred from the documented uses; cross-tenant data exposure has not been confirmed. Phoenix configuration, Langflow integration documentation
Teams using this integration can check record attribution during interleaved execution with distinct projects and execution markers, and test whether one workflow continues to produce spans after another finishes. They should watch for whether upstream separates the lifecycle of tracing instrumentation from individual workflows, and whether regression tests cover both project isolation and early termination.