Hpropagate Laravel Package

Product Decisions This Supports

• Observability as a shippable feature, not a platform project. Header propagation is the plumbing behind trace/correlation IDs (x-request-id, x-correlation-id, B3 x-b3-*, W3C traceparent/tracestate). Adopting it lets you claim "end-to-end request tracing" for a fraction of the cost of an OpenTelemetry rollout.
• Roadmap sequencing: if your roadmap has "faster incident triage," "customer-impact attribution," or "audit trail per request," this moves those items from blocked on infrastructure to testable in a sprint.
• Build vs. buy (vs. borrow): the surface area here is tiny — it is a request/response middleware that copies an allowlisted set of headers into outbound clients. That makes the real decision adopt vs. fork vs. write 60 lines of middleware, not build a system. A fork is cheap insurance given the adoption signals.
• Multi-tenant and experimentation use cases: propagating x-tenant-id, x-request-id, feature-flag/baggage headers downstream is what makes tenant-scoped debugging, per-tenant SLAs, and A/B assignment consistent across services.
• Sets the header governance policy: which headers are allowed to cross service boundaries, which are stripped (Authorization, cookies, PII), and where trust boundaries sit. This is a product/security decision the library forces you to make explicitly — good, because it's cheaper than retrofitting it during an audit.
• Diligence flag before commitment: the repo is a Symfony bundle while the package slug suggests a Laravel target. Confirm the framework fit and supported version matrix before it enters a roadmap.

When to Consider This Package

Consider it when all of the following hold:

• You operate Symfony services (or a Symfony-based monolith splitting into services) with a meaningful volume of outbound HTTP calls — service-to-service, partner APIs, internal gateway.
• You have a concrete, near-term need for request correlation or trace IDs across hops, or for propagating tenant/feature context.
• Your HTTP client stack supports middleware/interceptor injection (Symfony HttpClient, Guzzle), so the integration is configuration rather than refactoring.
• You can define and own a strict header allowlist and strip sensitive headers at the edge.

Look elsewhere when:

• Maturity is a hard requirement. Zero stars, zero dependents, zero score means no community validation, no third-party bug surface tested, and single-maintainer risk. Do not make it a platform dependency without forking or pinning.
• You need production-grade tracing. OpenTelemetry PHP, the OpenTelemetry Symfony instrumentation, or Symfony's built-in TraceableHttpClient give you sampling, exporters, and span semantics this library does not.
• You're on Laravel. Despite the package slug, this is a Symfony bundle. On Laravel, use HTTP client middleware (or a small custom middleware) instead — don't force a framework mismatch.
• Propagation must survive async boundaries. Queues, jobs, gRPC, and message buses need context serialized into payloads; an HTTP-only middleware won't cover the gaps, and partial coverage produces misleading traces.
• You'd be propagating sensitive headers. Blanket propagation of auth/cookies is a security incident waiting to happen; if you can't enforce an allowlist, don't adopt.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, single-purpose library that makes our services automatically pass request-identification headers along with every outbound call. The business payoff is cheaper incident triage (we can follow one customer request across services instead of guessing), better support answers, and a credible audit trail — without funding a full tracing platform. The cost is low (a spike, not a program). The risk is maturity: near-zero public adoption, so we should treat it as evaluate-and-fork, not standardize-and-depend, and cap the investment until the spike proves value.

For engineering: It slots into the HTTP client as middleware, so integration is config plus an allowlist, roughly an evaluation spike rather than a refactor. It gives us correlation IDs now and a clean seam to swap in OpenTelemetry later. Two caveats to design around: it's HTTP-only (queues and gRPC need separate handling) and it's a Symfony bundle, so confirm version support; if either bites, the fallback is ~a day of in-house middleware.

For product/security: The main decision it forces is header governance — an explicit allowlist of what may cross service boundaries, with auth tokens, cookies, and PII stripped at the edge. That policy is worth having regardless of whether we keep the library, and it's the cheapest time to write it.

Recommendation: Run a one-sprint spike in a non-critical Symfony service, fork the repo under our org, and gate wider adoption on two outcomes — measurable MTTR/correlation wins, and a signed-off header allowlist. If either is missing, keep the in-house middleware fallback.