Request Id Bundle Laravel Package

Product Decisions This Supports

• Observability roadmap: correlation IDs vs. full distributed tracing. This package represents the lightweight end of the spectrum — a single ID stamped on every log line and outbound HTTP call. Adopting it (or its pattern) is the cheap first step before committing to OpenTelemetry, Datadog APM, or a tracing backend. The decision it informs: do we buy tracing infrastructure now, or buy six months of breathing room with correlation IDs?
• Incident response and support cost. Correlation IDs directly reduce mean time to resolution when a single user request fans out across services. If support tickets routinely require "which service logged this?", this is a lever on MTTR and on-call burden — quantifiable in engineer-hours per incident.
• Microservice decomposition readiness. A monolith-to-services split is not safe to ship without cross-service request correlation. This is a gating dependency for a decomposition roadmap item, not a nice-to-have.
• Build vs. buy vs. copy. The core capability is small — a request-scoped ID generator, a log processor to inject it into context, a middleware to read/generate the inbound header, and an HTTP client middleware to propagate it outbound. Realistically half a day to a day of engineering. The real decision is whether to take a third-party dependency in the request path versus implementing the pattern natively — not whether the feature is worth having. It is.
• Third-party dependency policy. With 3 stars, 0 dependents, and a last release in March 2023, this package is a useful test case for whether the team's dependency approval bar is being applied consistently. It also informs whether we need a formal "vendored pattern" escape hatch for small, unmaintained utilities.
• Framework standardization. If the org runs both Laravel and Symfony, this informs which observability primitives we standardize on so logs are comparable across both estates.

When to Consider This Package

• You are on Symfony. Despite being framed as a Laravel/PHP option, the Bundle naming and the vendor's history point to a Symfony bundle. On Laravel this will not install cleanly or idiomatically — the actionable output is the pattern, not the dependency.
• You need a reference implementation. Reading a ~200-line implementation is faster than designing one, and the header-propagation semantics (read inbound, generate if absent, forward outbound) are exactly the parts teams get subtly wrong.
• Small service count, no tracing investment yet. Two to five services, no APM, and a real need to correlate logs today.
• You will pin, vendor, or fork it. With no maintainer activity since 2023 and zero dependents, treat it as source code you are adopting, not a dependency you are tracking. Vendor it into the repo and own it.

Look elsewhere when:

• You are on Laravel. Use framework middleware plus a Monolog processor, or lean on what you already run — Sentry, Laravel Telescope, or an OpenTelemetry SDK all generate and propagate trace context.
• You already have APM or tracing. Datadog, New Relic, and OpenTelemetry already inject trace and span IDs. Adding a second, competing identifier creates two correlation schemes in one log stream and makes debugging worse, not better.
• You need a support contract, security patching, or an SLA. Three stars, zero dependents, and a stalled release cadence do not meet that bar — and this code sits in the hot path of every request.
• You are in a regulated or audited environment. You will be asked who maintains the dependency and how vulnerabilities are disclosed. There is no evident answer.

How to Pitch It (Stakeholders)

For executives: The capability is real and cheap — one correlation ID that follows a request across every service and every log line, so an engineer can answer "what happened to this user's request?" in minutes instead of an afternoon. That is a direct reduction in incident cost and on-call load. The package itself, however, is not a buy: it is essentially unmaintained (last release March 2023, three GitHub stars, no downstream users), and it appears to target Symfony rather than our Laravel stack. Recommendation: do not adopt the dependency; adopt the pattern. A native implementation is roughly one engineer-day, carries no supply-chain exposure, and is fully under our control. Budget the day, ship the capability, and revisit full distributed tracing as a separate, larger decision once we have volume to justify it.

For engineering: The requirements are a request-scoped ID (ULID or UUIDv4), inbound header read with generate-if-absent semantics, injection into every log record's context, and propagation on all outbound HTTP calls including queue jobs and scheduled commands — the last two are where most homegrown implementations silently break, and they are the first thing to test. Do not take this package as a dependency: it sits in the request path, has no maintainers, and its header names and log-context keys should match our own conventions rather than being inherited from an abandoned bundle. Use it as a design reference if useful. Coordinate with whoever owns the tracing decision so we do not end up with two competing ID schemes once APM lands.