Extension Propagator B3 Laravel Package

Product Decisions This Supports

• Interop / standards decision: W3C vs. B3. Informs whether the platform standardizes solely on W3C Trace Context or ships a compatibility layer so Laravel services can join traces initiated by Zipkin-based infrastructure (Envoy/Istio, NGINX, Spring Cloud Sleuth-era JVM services). This package is the B3 "compatibility layer" option.
• Migration sequencing. Supports a phased migration off Zipkin/B3 toward OTel-native backends: run dual propagation (B3 in, W3C through, B3 out) for a release cycle instead of a big-bang cutover.
• Build vs. buy for a ~100-line problem. B3 header extraction/injection is small and well-specified. The decision is really userland propagator vs. native extension: buy the extension only if per-request overhead at your QPS justifies the operational cost of shipping a compiled PHP extension.
• Observability roadmap / incident response. Trace continuity across the PHP hop directly affects MTTR for cross-service incidents and vendor escalation; a broken trace boundary is a recurring, hard-to-attribute support cost.
• Platform/architecture constraint check. Forces an explicit answer to "can we install PHP extensions in every environment we run?" (custom Docker base image: yes; Laravel Vapor, shared hosting, many managed PaaS: no). That answer often decides the tool.
• Vendor/OSS risk posture. 0 stars, 0 dependents, READONLY (no external PRs) means adopting makes you an early adopter bearing support and patching risk — a procurement/risk decision, not just a technical one.

When to Consider This Package

Consider it when all of the following hold:

• You have B3 in the estate already — Envoy/Istio sidecars, Zipkin backend, or JVM services emitting B3 — and the PHP hop currently breaks traces.
• You own the PHP runtime image (Dockerfile/PECL builds, php.ini control) and can promote a compiled extension through staging to prod with the same rigor as any other binary dependency.
• You are at a request volume where userland propagation overhead is measurable (or you have a hard per-request latency budget), which is the only real reason to prefer native over a userland TextMapPropagator.
• You can pin the version and accept single-vendor maintenance, with a fallback plan (fork or drop to userland) if releases stall or the PHP version matrix lags your upgrade cadence.

Look elsewhere when:

• The platform is Vapor/serverless, shared hosting, or a managed PaaS that won't accept custom extensions — use a userland B3 propagator instead (or vendor a tiny implementation behind the Propagator interface).
• You only ever talk to W3C Trace Context consumers — use the SDK's built-in W3C propagator; adding B3 buys nothing.
• Traffic is modest and the cost is purely operational — the native extension's benefit is unlikely to clear the build-pipeline and on-call cost.
• You need guaranteed upstream responsiveness (CVE turnaround, PHP minor-version support, Windows/thread-safety guarantees). Low adoption + READONLY means you should treat it as a vendored component, not a community-maintained one.

How to Pitch It (Stakeholders)

To executives: We have a trace-continuity gap at the PHP boundary — requests that originate in our mesh or from our Java services arrive at Laravel with B3 headers we currently discard, so traces stop at the edge. This extension lets Laravel participate in those traces without re-architecting the observability stack, which shortens incident diagnosis and reduces cross-team escalation time. The trade-off is operational, not financial: it adds a compiled PHP extension to our image build, and the project has near-zero community adoption, so we would own the risk. Recommendation: fund a one-service spike behind the existing build pipeline, with go/no-go gated on "can we ship and roll back the extension in prod?"

To engineering: It's a focused, native B3 propagator from the OpenTelemetry PHP org — plug it in as the propagator and the SDK handles extract/inject. It's fast and avoids per-request userland parsing, but it's a binary dependency: image rebuilds, php.ini wiring, and a version pin. Repo is READONLY with no dependents, so plan to pin exactly, verify the PHP-version matrix against our upgrade cadence, and keep a userland B3 propagator as a documented fallback. If we can't demonstrate a latency win over the userland path, don't take on the build burden.