Tracing with LangFuse

[WilHoge]

Hi,
I configured OpenRAG with LangFuse tracing but don't see any traces in LangFuse.
Any idea what might be missing or how to debug the problem?
Wilfried

[TanbirRamim]

In OpenRAG the tracing is done by Langflow, not by the OpenRAG backend, so the three variables have to reach the langflow container. In docker-compose.yml only the langflow service gets LANGFUSE_SECRET_KEY, LANGFUSE_PUBLIC_KEY and LANGFUSE_HOST (right next to LANGFLOW_DEACTIVATE_TRACING), and Dockerfile.langflow installs the langfuse package into that image. A few things to check, in order:

1. Are the values actually inside the container? docker compose exec langflow env | grep LANGFUSE. If you added them to .env after the first docker compose up, recreate the service: docker compose up -d --force-recreate langflow. Langflow only reads the keys at startup.
2. LANGFUSE_HOST must be reachable from inside the langflow container, not from your shell. For a self-hosted Langfuse on the same machine use http://host.docker.internal:3000 (that is the example in .env.example); http://localhost:3000 points at the langflow container itself. Leave it empty only for Langfuse Cloud. Also make sure the keys come from the same Langfuse project you are looking at, and that the host matches the region (EU cloud.langfuse.com vs US us.cloud.langfuse.com).
3. Make sure LANGFLOW_DEACTIVATE_TRACING is not set to true anywhere (.env or compose override), it switches all Langflow tracers off.
4. Traces are created per flow run, so trigger a chat or an ingestion after the restart and check docker compose logs langflow for langfuse errors (auth failures and unreachable host show up there).

The reference table in docs/reference/configuration.mdx and Langflow's own Langfuse integration page describe the same three variables if you want the official wording.

[WilHoge]

Hi,

Thanks a lot for the detailed checklist!

I was able to identify and resolve the issue. In my case, the environment variables and network reachability were configured correctly, but checking the logs (docker compose logs langflow) revealed an AttributeError during tracer setup:

[error] Error setting up LangFuse tracer service=langflow
AttributeError: 'Langfuse' object has no attribute 'start_span'

Root Cause

Checking the installed package version with /app/.venv/bin/pip show langfuse showed that langfuse 4.15.1 (v4 SDK) was installed. Langfuse v4 introduced breaking changes to the client API, whereas the Langflow version used in OpenRAG expects the v3.x SDK API (where start_span is available).

Temporary Fix

Downgrading langfuse to v3 inside the container immediately solved the problem:

docker compose exec langflow /app/.venv/bin/pip install "langfuse>=3.0.0,<4.0.0"
docker compose restart langflow

After triggering a flow run, all traces started showing up in the Langfuse dashboard as expected.

Question regarding dependencies

To make this permanent and avoid pulling langfuse v4 again on container rebuilds: where is the recommended place in OpenRAG / Dockerfile.langflow (or the respective dependency files) to pin the langfuse version to langfuse>=3.0.0,<4.0.0?

Thanks again for pointing me in the right direction!

Best regards,
Wilfried

[TanbirRamim]

Nice find, thanks for writing up the root cause. That's a real bug in the image then: Dockerfile.langflow installs langfuse unpinned, so every fresh build now picks up v4 and the tracer silently fails. Pinning langfuse<4 there (or whatever version the bundled Langflow expects) would fix it for everyone, probably worth an issue or a small PR. If this thread solved it for you, marking it as the answer helps the next person searching for that AttributeError.