bug(v4.36.1, events_only): Traces UI list queries legacy traces table

Describe the bug

In self-hosted Langfuse v4.36.1 with LANGFUSE_MIGRATION_V4_WRITE_MODE=events_only, newly ingested OTLP traces are successfully stored in events_full and events_core, and their observations are returned by the v2 observations API. However, the Traces page does not list these traces and continues to show only traces created before switching to events_only.

The onboarding check works correctly after #14901 and the Traces page opens. However, source inspection shows that the traces.all list path still reaches getTracesTable() / getTracesTableCount(), whose query uses:

FROM traces t FINAL

The legacy traces table is intentionally not populated in events_only, so new traces cannot appear in this list.

Expected

The Traces UI should aggregate and list traces from the events data model when events_only is active.

Actual

Only rows already present in the legacy traces table are shown. New traces present in events_core are absent from the list.

Steps to reproduce

1. Deploy Langfuse v4.36.1 in self-hosted mode.
2. Set LANGFUSE_MIGRATION_V4_WRITE_MODE=events_only on the web and worker.
3. Send valid OTLP traces to /api/public/otel/v1/traces.
4. Confirm that the requests return HTTP 200.
5. Confirm that the corresponding rows exist in events_full and events_core, but not in the legacy traces table.
6. Query /api/public/v2/observations?traceId=<trace-id> and confirm that the observations are returned.
7. Open the project's Traces page.

The newly ingested traces are absent from the list.

Langfuse Cloud or self-hosted?

Self-hosted

If self-hosted, what version are you running?

4.36.1

SDK and integration versions

• Langfuse Python SDK: 4.15.2
• ioredis: 5.10.1
• Redis: 3-node Sentinel cluster with TLS
• Kubernetes (TKG), self-hosted

Additional information

Runtime configuration was checked on both pods:

• Web: v4.36.1, WRITE_MODE=events_only
• Worker: v4.36.1, effective WRITE_MODE=events_only
• One web replica and one worker replica

Verification results:

• 30/30 OTLP requests returned HTTP 200
• 30/30 test traces are represented in events_full and events_core
• 30/30 are accessible through the v2 observations API
• 0/30 have rows in the legacy traces table
• 0/30 appear in the Traces UI list
• The legacy table contains 181 older traces, and those are still displayed

One correlated example contained 21 observations in events_core, including an is_app_root=true observation, and all 21 were returned by the v2 API. The trace was still absent from the Traces list.

PR #14901 fixed the hasAnyTracingData onboarding check by routing it to events_core in events_only. It does not appear to route the actual traces.all list/count path.

The v1 traces API returning 404 in events_only is expected and is not part of this report.

No ingestion data loss was observed. This report concerns only the Traces UI read path.

Suggested fix: route the Traces list and count to the events-aware trace aggregation/read path when events_only is active, consistently with the events-aware onboarding and trace-detail paths.

Are you interested in contributing a fix for this bug?

No