Xrequestuid Bundle Laravel Package

Product Decisions This Supports

• Observability roadmap: "do we need request correlation IDs?" — This bundle exists to answer one question: when a request fans out across N microservices, how do we stitch the logs back together? That decision (yes/no, and at what layer) is a real roadmap item, and this package is useful mainly as a scoping artifact for it.
• Build vs. buy vs. adopt — It frames the cheapest viable version of the capability: generate a UID at the edge, propagate it as a header (typically X-Request-UID), and inject it into every log line via a Monolog processor. That is roughly a kernel event listener plus a processor, i.e. days of work, not a platform project.
• Incident response / MTTR targets — Correlation IDs are the enabling primitive for "given a customer complaint, find every log line for that request across services." If support escalations currently involve grepping timestamps, this is the lever.
• Logging standard definition — Forces a cross-team agreement on header name, propagation rules (trust inbound vs. always regenerate at the edge), and retention. That standard outlives any package.
• Vendor / dependency governance — The v3.0.1 release is itself a decision input: a previously archived, unmaintained dependency publishing again is a supply-chain signal to verify (who tagged it, what changed, is it still archived?) before it sits in anyone's composer.lock.
• Feature-level use cases it covers — Request tracing in dev/staging, per-request log enrichment, surfacing a request ID in error responses so customers can quote it to support.

Important correction for the record: despite the "Laravel/PHP package" framing, this is a Symfony bundle (m6web/xrequestuid-bundle), not Laravel. It has no applicability to a Laravel codebase without a port of the bundle's listener/compiler-pass wiring.

When to Consider This Package

The recommendation is unchanged: do not adopt as a dependency. What changed is one input, not the conclusion. A v3.0.1 release now exists on a package previously recorded as last released January 2020 — meaning a 3.x line and at least one patch landed without appearing in our prior data. That release note is a bare "see #8," with no changelog, no migration notes, no stated scope, and no indication of who cut the tag.

Treat that as an open question, not a revival:

• Verify provenance before anything else — is the upstream repo still archived, was it transferred/forked, and who has tag rights? An unexplained patch release on a dormant package is a supply-chain question, not a feature.
• Read issue/PR #8 directly — until someone does, we cannot claim PHP 8 / Symfony 5+ compatibility (a plausible content for a 3.x patch, but unverified), and we should not assume the deprecation notice was withdrawn.
• Assume the substantive signals still hold — deprecated, effectively unmaintained, negligible adoption (3 stars, 0 dependents), and pre-dating PHP 8 and W3C Trace Context. A patch bump moves none of these.

Consider it only as:

• A design reference — reading the listener/processor split to inform your own ~100-line implementation.
• A legacy maintenance context — you already run a Symfony 3.x/4.x app that depends on it and removal costs exceed carrying costs, and only as a tracked technical-debt item with a removal date.

Look elsewhere — or build — when:

• You are greenfield or on Symfony 5+/Laravel 9+/PHP 8.1+. Use a framework-native listener or a Monolog processor you own.
• You need standards-compliant tracing: adopt W3C Trace Context (traceparent/tracestate) and OpenTelemetry so you interoperate with APM vendors and service meshes rather than inventing a proprietary X-Request-UID.
• You already have an APM/observability vendor (Datadog, New Relic, Sentry, Honeycomb) — their SDKs do this and much more; a bespoke bundle is duplicate spend.
• You need vendor support, SLAs, or an auditable security posture — a single opaque patch release does not establish any of these.
• Cross-language services are in scope — a PHP-only bundle cannot propagate through Go/Node/Python services; a header convention can.

How to Pitch It (Stakeholders)

To executives: Our recommendation is unchanged — do not adopt this package. One new data point crossed our desk: a v3.0.1 patch was published on a package we had recorded as dead since January 2020, with release notes that only point at an internal issue and no changelog. That is not evidence of renewed maintenance, and it does not offset the reasons we passed: deprecated status, negligible adoption, no security-patching track record, and no vendor accountability. The capability remains worth having — it cuts incident diagnosis time and lets support trace one customer request across services — and we can build it in roughly a day. Recommendation: fund a small logging-standard workstream (header convention + log enrichment) aligned to OpenTelemetry / W3C Trace Context, and close this evaluation. No budget, no procurement, no dependency.

To engineering: Do not vendor this. It is a Symfony bundle, not Laravel, and one unexplained patch release does not make it live upstream. Before anyone composer requires it on the strength of the version bump, spend thirty minutes confirming repo status and what PR #8 actually changed — if it is PHP 8 compatibility, that is table stakes, not a feature. Its entire value is a kernel request listener that mints an ID plus a Monolog processor that stamps it onto log records: trivially reimplementable, and we should own it so we control propagation semantics (regenerate at the edge, trust internally) and framework-version compatibility. If we want to interoperate with APM and non-PHP services, go straight to OpenTelemetry's PHP SDK plus traceparent propagation rather than a proprietary header. Use the repo as a reference read only; no code dependency.