Request Id Bundle Laravel Package

Product Decisions This Supports

• Observability and incident response: A request-ID package assigns a unique correlation ID per inbound request (typically via header such as X-Request-ID) and makes it available to logs, responses, and downstream calls. This directly supports mean-time-to-resolution (MTTR) goals and support-ticket triage — a customer complaint can be traced to a single request across services.
• API/contract decisions: Whether to expose a correlation ID in error responses and accept client-supplied IDs (and under what trust rules) is a product-visible API design decision, not just an infra one.
• Build vs. buy: This is a small, commodity capability. The decision hinges on whether the package handles the hard edges — header propagation, trusted-proxy validation, async/queue job context, sub-requests, and consistent formatting — versus a ~30–50 line in-house middleware.
• Roadmap enabler: Prerequisite plumbing for SLA/uptime reporting, audit trails, multi-tenant debugging, and eventual distributed tracing. Adopting it now avoids retrofitting correlation later.
• Platform standardization: If multiple services adopt the same ID convention, it becomes a cross-team contract worth owning centrally.

When to Consider This Package

Consider adopting when:

• You need standardized request correlation across PHP services and have no APM/tracing agent already injecting trace IDs.
• You want drop-in middleware with sensible defaults rather than maintaining bespoke glue.
• You need to honor or generate inbound X-Request-ID (or similar) and propagate it to logs and outbound HTTP calls.

Look elsewhere or build in-house when:

• You already run Datadog/New Relic/Sentry/OpenTelemetry, which supply trace IDs — adding a second ID scheme creates confusion unless deliberately bridged.
• You need full distributed tracing (spans, sampling, context propagation across languages) — this is a correlation-ID utility, not a tracer.
• The package is Symfony-oriented. The name "bundle" suggests Symfony heritage; verify Laravel service-provider/middleware support and documentation before committing. No data was supplied to confirm Laravel compatibility.
• Queue/async propagation, trusted-proxy sanitization, or multi-tenant context is required and undocumented.
• Your stack is simple enough that a short, well-tested middleware you own is lower-risk than an external dependency.

Caveats for this release: Version 1.0.1 is a patch with an empty changelog (compare link only), indicating active but lightly documented maintenance. Pin the version, review the diff, and treat the changelog transparency as a minor maturity signal rather than a blocker.

How to Pitch It (Stakeholders)

To executives: A low-cost, low-risk utility that makes every request traceable in logs. It shortens incident investigation and support resolution time without infrastructure changes or vendor spend. Because the capability is small, the main decision is "adopt a maintained package vs. write a few dozen lines ourselves" — either is cheap; the package is justified if it saves ongoing maintenance.

To engineering: Drop-in request-correlation middleware with header generation/propagation and PSR-3-friendly logging. Low footprint, no runtime dependencies of consequence. Before adoption, confirm Laravel integration (the "bundle" naming hints at Symfony origins), define the trusted-header policy to prevent spoofed IDs, and confirm queue/job propagation behavior. The 1.0.1 patch has no functional detail in its notes — pin to 1.0.1, review the diff, and avoid floating constraints. If those checks pass, it replaces bespoke middleware with a maintained dependency; if they don't, a small internal middleware remains a reasonable fallback.