Propagate trace context between two fal apps so that preprocessing and inference appear as children of a single parent trace
When a request passes through more than one fal app, each app creates its own spans by default and those spans appear as separate, unrelated traces in your backend. Passing W3C trace context between apps connects them under a single trace ID, so preprocessing and inference show up as children of one root span. For single-app tracing, see Custom Traces.
The W3C Trace Context standard defines a traceparent header that carries a trace ID and parent span ID between services. The sending app injects the current span context into a carrier (a plain dict), passes it to the receiving app, and the receiving app extracts the context before creating its span. Both apps end up contributing spans to the same trace ID.fal apps communicate over HTTP, and the carrier is passed as a field in the JSON request body. Both apps must export to the same OTLP backend for the spans to be correlated.
Deploy TextToImageWorker first to get its app id, then deploy ImagePipeline and pass the app id when calling it.
fal deploy pipeline.py::TextToImageWorker# Note the app id, e.g. your-username/text-to-image-workerfal deploy pipeline.py::ImagePipeline
Both apps must have OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS set as fal secrets. See Custom Traces for backend options and how to store credentials.
The inference span in TextToImageWorker is a child of image-pipeline in ImagePipeline because _propagator.extract(input.trace_context) reconstructed the parent context before the span was created.The entity map shows both apps connected, and the span tree shows spans from both services under the same trace ID:
Both apps must export to the same OTLP backend for the trace to appear connected. If each app sends spans to a different backend, they will not be correlated even though they share a trace ID.