Supabase fixes broken client trace propagation and now preserves trace IDs even for unsampled requests

Supabase’s original August 18 tracing release linked supported client traces to API Gateway and Edge Function logs but had an important sampling limitation: before supabase-js 2.112.3, an unsampled upstream trace could result in no trace headers being sent at all. Current Supabase documentation now states that from 2.112.3 onward, non-sampled requests still carry `traceparent` with the sampling flag preserved, while `tracestate` and `baggage` remain suppressed by default. That keeps backend log correlation working without forcing full sampling. The newer SDK also emits one-time warnings for several propagation misconfigurations, and Supabase’s browser Edge Function guidance now requires CORS allowlists to include `traceparent`, `tracestate` and `baggage`; functions using older SDK-derived CORS headers need to update and redeploy.

Distributed tracing is only useful when the identifier survives the boundary developers are trying to debug. The 2.112.3 behavior means teams can keep normal sampling policies while still correlating a browser request to Supabase backend logs, instead of choosing between sampling cost and trace-ID continuity. The new diagnostics also reduce the risk of believing tracing is working when no active span, tracing runtime or compatible propagator is actually present. For browser-to-Edge-Function calls, however, the fix introduces an operational migration detail: old CORS allowlists can block the new W3C headers until the function is redeployed with an updated allowlist.

As of supabase-js 2.112.3, the default `respectSamplingDecision: true` behavior no longer drops all tracing headers for an unsampled upstream span. The SDK sends `traceparent` with the sampled flag preserved and omits `tracestate` and `baggage`. Supabase can therefore stamp the same trace ID into backend logs even though downstream tracing systems correctly treat the span as unsampled.

supabase-js 2.106.0 through 2.111.x silently failed to propagate trace headers in bundled applications when the OpenTelemetry API was unavailable. The supported path remains 2.112.0 or later with an explicit `@supabase/supabase-js/tracing` import. Teams that enabled tracing on affected versions should continue treating historical trace continuity as incomplete.

The current SDK documents one-time warnings when tracing is enabled but the runtime is not loaded or when the active propagator does not emit W3C `traceparent`. This preserves Supabase’s non-throwing behavior while making common configuration mistakes easier to diagnose from the browser or server console.

Browser requests to Edge Functions can only carry the tracing headers if the function’s CORS allowlist permits them. Supabase says the SDK-provided `corsHeaders` includes `traceparent`, `tracestate` and `baggage` from version 2.112.3. Functions deployed with older allowlists need to update the dependency or add the headers manually and redeploy before browser trace propagation will work.

The trace ID is currently surfaced in API Gateway and Edge Function logs, and the SDK only attaches trace context to Supabase project domains and local development hosts. Database, Auth, Storage and Realtime logging do not yet form one universal end-to-end trace surface, so builders should still document exactly which service boundaries can be correlated.