fix: OpenTelemetry trace context propagation

[ringerc]

Add trace context propagation to outbound requests to Langflow, so that an incoming OpenTelemetry trace context is properly linked to outbound trace contexts.

Fixes #12961

This fix makes it possible to use a fake Langwatch or Arize endpoint to deliver traces to an otel-collector with working trace context propagation to downstream services.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: eeb6690f-d205-497d-b8e5-77005f3e7358

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Qodo-Free-For-OSS]

Hi, Both tracers instrument and uninstrument requests/urllib3 per tracer instance even though these instrumentors monkeypatch globally; ending one trace can disable propagation for other in-flight traces or other tracer instances still running.

Severity: action required | Category: reliability

How to fix: Make instrumentation process-scoped

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

RequestsInstrumentor/URLLib3Instrumentor patch globally, but tracers call instrument()/uninstrument() per trace. If multiple graph runs overlap, the first run to call end() will uninstrument globally and break context propagation for other active runs.

Issue Context

Instrumentation should be enabled once per process (or reference-counted), not tied to a single tracer instance’s lifecycle.

Fix Focus Areas

• src/backend/base/langflow/services/tracing/langwatch.py[94-130]
• src/backend/base/langflow/services/tracing/arize_phoenix.py[219-252]
• src/backend/base/langflow/services/tracing/service.py[264-347]

Implementation notes

• Introduce a shared instrumentation manager (module-level singleton) with ref-counting:
  • enable(tracer_provider) increments count and instruments only on first enable.
  • disable() decrements count and uninstrument only when count reaches zero.
• Alternatively, instrument once at application startup (TracingService init) and never uninstrument; rely on OTel context to control propagation.
• Ensure provider selection doesn’t unexpectedly change if already instrumented (document or keep first provider).

---

Qodo code review - free for open-source.

[Qodo-Free-For-OSS]

Hi, _uninstrument_http_clients suppresses all Exceptions, so failures to remove global monkeypatches are silent and leave the process in an unknown instrumentation state.

Severity: remediation recommended | Category: observability

How to fix: Log unexpected uninstrument errors

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

Uninstrumentation currently suppresses any exception, hiding unexpected failures and making debugging difficult.

Issue Context

It’s fine to suppress ImportError when optional instrumentation packages are missing, but other exceptions should be logged (at least debug/warn).

Fix Focus Areas

• src/backend/base/langflow/services/tracing/arize_phoenix.py[240-252]
• src/backend/base/langflow/services/tracing/langwatch.py[117-129]

Implementation notes

• Replace contextlib.suppress(ImportError, Exception) with:
  • suppress(ImportError) for the import
  • try/except Exception as e around uninstrument() with logger.debug(...) or logger.warning(...) including exception info.
• Keep behavior non-fatal (do not raise).

---

Found by Qodo code review

[ringerc]

Those comments look reasonable. I'll look into it.

[ringerc]

These revisions should address the concerns expressed; see b6dd9dc in particular.

LLM used to generate the shared context manager as Python isn't my string suit.

[erichare]

LGTM, thanks @ringerc !

[ringerc]

Greatly appreciated @erichare

If you get a chance to look over my related PR to support generic OTLP protocol, that'd be great. I'll rebase it onto this.