deps: bump langfuse to v4 + migrate tracer/tests off v3 APIs#13277
deps: bump langfuse to v4 + migrate tracer/tests off v3 APIs#13277thesaadmirza wants to merge 6 commits into
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThe PR updates the ChangesLangfuse v4 compatibility
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error, 1 warning)
✅ Passed checks (7 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/backend/base/pyproject.toml`:
- Line 237: The pyproject was bumped to langfuse>=4 but
src/backend/base/langflow/services/tracing/langfuse.py and its tests are written
against the v3 API (LangFuseTracer class, imports of
langfuse._client.span.LangfuseSpan and langfuse.types.TraceContext, calls to
self._client.start_span, span.update_trace, span.update, Langfuse.start_span and
get_langchain_callback/CallbackHandler), so either pin the dependency to <4 or
migrate the tracer and tests to v4: update imports to v4 module paths, replace
start_span/start_generation usages with start_observation and the new
observation methods, switch trace attribute propagation to
propagate_attributes/observation-level APIs, adapt or remove CallbackHandler
usage per v4, and update
src/backend/tests/unit/services/tracing/test_langfuse_v3_compatibility.py to
validate the new v4 behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 3a2000a5-f5b3-4656-84a3-56d4b68ee14d
📒 Files selected for processing (1)
src/backend/base/pyproject.toml
Pin: langfuse~=3.8; python_version < 3.14 → langfuse>=4,<5 The pyproject conditional silently skipped install on Python 3.14 (the runtime in langflowai/langflow:1.9.3). v4.6.1 is pydantic-v2 / Python-3.14 compatible. Tracer rewritten for v4 surface: - client.start_span → client.start_observation - span.start_span → span.start_observation - update_trace(name, user_id, session_id) → propagate_attributes(...) entered in _setup_langfuse, exited in end() - update_trace(input, output) → set_trace_io(input, output) - end()/update()/CallbackHandler signatures unchanged Tests file renamed v3_compatibility → v4_compatibility; mocks updated to v4 surface (start_observation + propagate_attributes context manager). All 12 tests pass against langfuse 4.6.1 inside langflowai/langflow:1.9.3.
34f366a to
b26f024
Compare
propagate_attributes was held across the tracer's whole life, but child spans run in a worker task whose contextvars predate the token, so user.id/session.id never landed on them. Per-call wrap fixes it.
Bug
src/backend/base/pyproject.toml(at v1.9.3 +main) pins:The environment marker means on Python 3.14 the langfuse SDK is not installed at all.
Reproduced against the published image:
requires-python = ">=3.10,<3.15"and the published Dockerfile usespython:3.14-slim-trixie, so this is the default path. SettingLANGFUSE_*env vars on a default install produces"Could not import langfuse"on every flow run (langfuse.py:101).Fix
Bump the pin to v4 AND migrate the tracer + tests off the v3 API. The first version of this PR only touched the pin — @coderabbitai correctly caught that the tracer code calls v3-only methods (
client.start_span,span.update_trace) which don't exist on v4. Single-line pin bumps would break tracing at runtime; the full migration is below.Pin change
Tracer migration (
src/backend/base/langflow/services/tracing/langfuse.py)client.start_span(...)client.start_observation(...)span.start_span(...)span.start_observation(...)root.update_trace(name=, user_id=, session_id=)propagate_attributes(trace_name=, user_id=, session_id=)context manager, entered in_setup_langfuse, exited inend()root.update_trace(input=, output=)root.set_trace_io(input=, output=)span.update(...),span.end(),Langfuse.create_trace_id(...),CallbackHandler(trace_context=...)The
propagate_attributesCM is the load-bearing piece — trace attributes are no longer span parameters, they propagate via OTel context. Manually entering and exiting (rather than wrapping the whole tracer lifecycle in awithblock) keeps the proceduralBaseTracerinterface intact.Test migration
tests/unit/services/tracing/test_langfuse_v3_compatibility.py→test_langfuse_v4_compatibility.py. Mocks updated to v4 surface (start_observation+ a context-manager-shapedpropagate_attributes). Removed v3-specific assertions (update_tracecount,start_spancalls); added v4 assertions (propagate_attributesinvoked withtrace_name/user_id/session_id,set_trace_iocalled inend(),start_observationon root + child).Verification
All 12 tests pass against the real
langfuse==4.6.1insidelangflowai/langflow:1.9.3:Plus a live-tracer round-trip (constructed tracer →
add_trace→get_langchain_callback→end_trace→end→ all v4 calls executed, OTel context entered/exited cleanly).Why v4
~=3.8) depends on pydantic v1 internals incompatible with Python 3.14 (the spike that prompted thepython_version < '3.14'marker in the first place — see PR #11216 precedent for v2→v3).Note on
langwatchTwo lines below the langfuse pin,
langwatch~=0.10.0; python_version < '3.14'has the same bug pattern. Out of scope for this PR; flagged here in case someone wants to file a follow-up.Related
~=3.8); this is the v3→v4 follow-up