Request Id Bundle Laravel Package

Product Decisions This Supports

• Observability foundation (build vs. buy): A request/correlation ID is the cheapest possible lever for making logs, traces, and error reports joinable across a Symfony application. This bundle is a buy-and-forget dependency rather than a sprint of internal plumbing — adopt it instead of hand-rolling a kernel listener plus Monolog processor.
• Incident triage and support workflows: A consistent ID per request lets support and on-call staff pull "everything that happened for this one user action" out of a log aggregator without timestamps-and-guessing. This directly reduces mean time to resolution and is a prerequisite for any credible post-mortem process.
• Distributed tracing roadmap: If the roadmap includes moving to OpenTelemetry or a hosted APM (Datadog, Sentry, Honeycomb), a request ID that propagates to downstream calls is the seam those tools attach to. Choosing this now avoids re-instrumenting later.
• Cross-service correlation for API products: For any public or partner-facing API, echoing the request ID back in the response header is a supportability contract — it turns "your API is broken" tickets into reproducible lookups.
• Compliance and auditability: Sequential per-request identifiers give you a defensible audit trail linking a user-visible transaction to internal processing steps, which is often a checkbox in security reviews and SOC 2 style assessments.
• Platform currency (v1.9.0 relevance): Symfony 8 support in v1.9.0 is a forward-compatibility signal, not a feature. It means this dependency will not block a Symfony major-version upgrade in the next planning cycle — a small but real input into "when do we schedule the framework upgrade" decisions.

When to Consider This Package

Adopt it when most of the following are true:

• The stack is Symfony (5.4+/6.x/7.x/8.x). Caveat worth stating plainly: this is an SBSEDV Symfony bundle, not a Laravel package. If the application is Laravel, the native Context facade plus a middleware covers the same ground, and equivalent community packages exist — this assessment's adoption criteria carry over, the specific dependency does not.
• You already ship or are about to ship centralized logging; an ID with nowhere to be searched is wasted effort.
• You have more than one service, or one service plus a queue/worker tier, where correlating an async job back to the originating HTTP request has real debugging value.
• You want the convention (header name, generation strategy, propagation) standardized rather than re-litigated per team.
• v1.9.0 specifically: you are planning or actively executing a Symfony 8 migration, or you pin to the newest major and want dependents that keep pace. Teams on Symfony 6/7 see no behavioral change from this release.

Look elsewhere when:

• You need full distributed tracing with spans, sampling, and baggage — use the OpenTelemetry Symfony instrumentation instead; a request ID is a subset of that capability.
• The stack is Laravel, or you require first-class non-Symfony HTTP kernel support.
• Your logging pipeline cannot index new fields, or your log volume makes per-request IDs unaffordable.
• You need built-in PII scrubbing or log redaction — that belongs to the logging layer, not this bundle.
• The application is a single-process monolith with one log file and no aggregator; a request ID adds negligible value over a timestamp.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk dependency that makes every support ticket and incident reproducible. When a customer reports a failure, we can locate the exact request in our logs in seconds instead of reconstructing timelines by hand — that shortens outages and reduces support cost. It is a building block for the monitoring investments already on the roadmap, and the current release keeps us compatible with the newest Symfony version so it will not become upgrade debt.

To engineering: A maintained bundle that generates and propagates a request ID through the Symfony kernel and into your logging context, so Monolog lines, error reports, and downstream HTTP calls all carry the same identifier. Version 1.9.0 adds Symfony 8 support — no breaking changes, no new API surface, no action required beyond a routine bump. It replaces a small custom listener and Monolog processor with a versioned dependency, and it gives us a standard header convention for free. Trade-off to accept consciously: it is Symfony-only and not a substitute for real tracing — treat it as the correlation layer beneath OpenTelemetry, not a replacement for it. Recommend upgrading on the normal cadence and adding it to the Symfony 8 migration checklist as "already ready."