Request Id Bundle Laravel Package

Product Decisions This Supports

• Observability strategy / logging standard: request (correlation) IDs are the cheapest way to make logs joinable across services. This package represents one implementation of the "every request carries an ID, every log line includes it, every response echoes it" convention — a decision worth standardizing on regardless of vendor.
• Build vs. buy vs. adopt: the entire capability is a request/response listener plus a header convention. It informs the standing decision of whether to pull a dependency for ~100 lines of glue or own it in a shared internal package.
• Incident response and support workflows: enables a "give us the request ID from the error page" support flow, which changes how you design error pages, API error envelopes, and ticket intake.
• Distributed tracing seed: the request ID is the natural entry point for propagating trace context to downstream services and queues; supports roadmap work on APM adoption (OpenTelemetry, Sentry, Datadog) and header propagation standards.
• API contract decisions: whether X-Request-ID is accepted from clients, generated server-side, or both; whether it is returned on error responses only or all responses; whether it is part of your public API guarantees.
• Framework fit check: this is a Symfony bundle, not a Laravel package. If the estate is Laravel, this does not apply — the equivalent is a small middleware. That is itself a portfolio decision: standardize the convention, not the artifact.

When to Consider This Package

Consider it only when all of the following hold:

• The service is Symfony (bundle registration, kernel event listeners). On Laravel, Slim, or plain PHP this package is not usable without a rewrite.
• You want request-ID behavior now, with a permissive MIT license, and you accept reading the source before trusting it.
• You treat it as a reference implementation rather than a long-term dependency — something to vendor or reimplement into your own shared bundle with tests and your header conventions baked in.

Look elsewhere (or build in-house) when:

• Maintenance risk matters. Zero stars, zero dependents, no release since March 2021. There is no community to catch regressions, no security response path, and no evidence of production use. For a package this small the risk is low in absolute terms, but so is the cost of owning it.
• You need more than a pass-through ID. If the requirement includes trace-context propagation (W3C traceparent), log-processor integration, async/queue propagation, or sampling, use an established observability SDK — those solve a superset and are actively maintained.
• You have a platform/standards team. A cross-cutting logging convention belongs in an internal foundation package, not scattered per-service third-party bundles.
• You require vendor support, SBOM provenance, or a documented security policy.

Net: adopt as inspiration, not as infrastructure. The recommendation to engineering is to port the behavior into an owned package — roughly a day of work — and pin your own header and logging conventions.

How to Pitch It (Stakeholders)

For executives: This is a tiny, free utility that stamps a unique ID on every incoming request so that logs, errors, and support tickets can be tied back to a single user action. The capability is genuinely valuable — it measurably shortens incident triage and cuts "we can't reproduce it" support cycles. The artifact, however, is a zero-adoption Symfony bundle last touched in 2021, so I do not recommend taking it as a dependency. I recommend we adopt the convention and implement it ourselves as an internal standard.

For engineering: The package is a thin Symfony request/response listener that reads or generates a request ID and puts it on the response and into log context. Two caveats: (1) it is Symfony-only — Laravel services need equivalent middleware; (2) it is unmaintained since 2021 with no dependents, so treat it as a spec, not a dependency. Proposal: a shared internal package providing (a) accept-or-generate semantics for X-Request-ID, (b) echo on all responses including errors, (c) log processor injection, (d) propagation into queued jobs and outbound HTTP. That gives us one convention across frameworks, tests we control, and no bus-factor exposure on a 0-star repo.

Decision requested: Approve standardizing the request-ID convention and funding the small internal implementation, rather than adopting this bundle as-is.