Inter App Request Identifier Bundle Laravel Package

Product Decisions This Supports

• Correlation-ID / distributed-tracing strategy. The package encodes one narrow idea: a named contract so that a single logical process spanning several applications can be identified consistently. That is a product-observability decision, not a library decision — it determines whether support can answer "where did this customer's checkout stall?" in minutes or hours.
• Support-cost and incident-response budget. A shared request identifier across services is the cheapest lever for reducing mean time to resolution. It directly affects headcount math on the support and on-call side, which is a roadmap-adjacent line item most PMs never see.
• Audit and compliance posture. Any multi-app flow (payments, order fulfilment, KYC) that must be reconstructed after the fact needs a stable identifier threaded end-to-end. This contract is the vocabulary for that requirement.
• Build vs. buy (the honest version). Still build it in-house. v0.2.0 ("activate Guzzle and Monolog by default if present") walks the package a small step past a pure interface — it now ships opinionated wiring that auto-attaches itself when Guzzle or Monolog are detected — but it remains a contract plus thin Symfony-side glue, with no propagation policy, ID format, sampling, storage, or retention decisions. The product work is still the propagation contract (header names, ID format, sampling, log correlation, retention), which no package can decide for you.
• Prior-art input to a design doc. Its genuine value is as a reference for naming, interface shape, and the "auto-wire the client and logger" pattern when writing an internal RFC on request correlation, alongside OpenTelemetry's W3C Trace Context.
• A cautionary data point on implicit wiring. The default-on activation in v0.2.0 is exactly the pattern to avoid in our own build: correlation behaviour should be explicitly enabled, not silently switched on because a library happens to be installed. Use it as an argument in the RFC, not as code to import.
• Explicitly not supported: framework selection, feature prioritisation, or any buy decision. With 0 stars, 0 dependents, an archived repository, and no release since March 2018, there is no adoption signal whatsoever — a single follow-up commit does not constitute a maintenance signal.

When to Consider This Package

Adopt only if all of the following hold:

• You are on a legacy Symfony stack (roughly Symfony 3/4, PHP 7.x) — this is a Symfony bundle, not a Laravel package, and it will not register cleanly in Laravel's service container without a custom bridge you would have to own.
• You need only a shared interface plus best-effort Guzzle/Monolog wiring across a set of first-party apps you also control, and you have already designed the propagation and storage layers yourself.
• You are comfortable with behaviour that enables itself based on what is installed — and can guarantee that is acceptable in every environment where the bundle loads (including test and CLI).
• You accept permanently owning the code, since upstream maintenance has ended.

Look elsewhere — or build — if any of these are true:

• You are on Laravel. The bundle's Symfony DI extension, configuration tree, and service tagging are dead weight; a plain PHP interface plus a Laravel middleware and a log processor is smaller and idiomatic. Note that v0.2.0's Guzzle hook would sit underneath Laravel's HTTP client wrapper and its Monolog hook would compete with Laravel's contextual logging — two overlapping mechanisms for the same job.
• You need working behaviour you can reason about: explicit header propagation, queue/cross-process hand-off, log enrichment, or trace visualisation. Use OpenTelemetry (PHP SDK) with W3C Trace Context — actively maintained, vendor-neutral, explicit about configuration, and the format your observability vendor already ingests.
• You need framework-native correlation IDs: Laravel's contextual logging, Monolog processors, and X-Request-Id middleware conventions cover this in an afternoon.
• Dependency hygiene matters (it should): an archived 2018 package with zero dependents is a supply-chain and knowledge-transfer liability, and auto-activation increases the blast radius of that liability rather than reducing it.

How to Pitch It (Stakeholders)

To executives: We re-evaluated a small open-source component that defines a shared identifier for a single process spanning multiple applications. A new release adds automatic wiring for Guzzle and Monolog when those libraries are present, but the project remains an interface plus thin glue — no propagation policy, no storage, nothing that answers the operational questions — is archived, has no known users, and targets Symfony rather than our Laravel stack. Recommendation unchanged: do not adopt; reuse the concept. We will implement request correlation ourselves as a thin, well-tested layer (an interface plus Laravel middleware and a log processor), roughly a few days of engineering, explicitly enabled at boot. The payoff is measurable: faster incident diagnosis and a reconstructable audit trail across our multi-service flows. Any build should align to the W3C Trace Context standard so we can adopt OpenTelemetry later without rework.

To engineering: This is prior art, not a dependency. The v0.2.0 release is worth reading precisely because it shows the failure mode: it switches on Guzzle middleware and Monolog handlers based on what happens to be installed, which makes runtime behaviour depend on the composer graph. Use it as a naming and shape reference, then write our own contract in our own namespace, with an explicit decision recorded on ID format (UUIDv4 vs. W3C trace-id), header name, propagation points (HTTP in/out, queued jobs, console commands), log enrichment, and — importantly — that activation is an explicit config flag, never presence-detected. Do not vendor the bundle; do not add the abandoned Symfony DI wiring to a Laravel app. If we need the full capability rather than the contract, OpenTelemetry is the maintained path and should be evaluated against our observability vendor's support.

Bottom line for the product decision log: Rejected for adoption on maintenance, stack-fit, and scope grounds; accepted as design input to an in-house correlation-ID capability. v0.2.0 reviewed on re-release — adds implicit Guzzle/Monolog activation only; no change to the recommendation, and the implicit-activation pattern reinforces the case for building our own.