Weave Code
Request Id Bundle Laravel Package
sbsedv/request-id-bundle
Symfony bundle that generates a unique request ID for each incoming request and propagates it through logs and responses, making it easier to trace errors and correlate activity across services. Configurable headers and ID generation support debugging in distributed applications.
A Symfony bundle that adds a unique Request-ID.
Frequently asked questions about Request Id Bundle
- Is sbsedv/request-id-bundle a Laravel package?
- No. It is a Symfony bundle, not a Laravel package, so you cannot install and enable it in Laravel the way you would a Composer package with a service provider. Laravel has no bundle system, so you would reimplement the same three pieces: middleware that generates or validates an ID, Log::withContext() for log correlation, and a response header. It is still useful as a reference behavior if you are standardizing request-ID semantics across mixed Symfony and Laravel services.
- How do I install and enable sbsedv/request-id-bundle in a Symfony application?
- Install it with Composer, then enable the bundle in config/bundles.php. Configuration is simple Symfony service wiring, with options for request and response header names and the ID generator. There are no database migrations, queues, external services, or credentials required.
- Does sbsedv/request-id-bundle support Symfony 8 and which PHP version do I need?
- Version 1.9.0 adds Symfony 8 support, and Symfony 8 requires PHP 8.4 or newer. Before upgrading, compare composer.json between 1.8.1 and 1.9.0 to confirm whether older Symfony majors are still allowed. If any service remains on Symfony 6.4 or 7.x, verify the constraints rather than assuming the minor release is purely additive.
- Does it accept an incoming X-Request-Id header or always generate a new ID?
- The bundle propagates an existing request ID when one is present and otherwise generates a unique ID per request. Request and response header names are configurable. Treat inbound IDs as untrusted: enforce length and charset validation to avoid log injection and attacker-controlled correlation IDs that poison tracing.
- How does the request ID get into Monolog logs?
- The bundle integrates with Monolog through a processor that attaches the request ID to log records, so every line emitted during a request can be correlated. Make sure the processor is wired and that your handler format includes log context. This log correlation is usually the main reason to use the bundle instead of only setting a response header.
- Is sbsedv/request-id-bundle safe for production and does it add overhead?
- Runtime risk is low because the package is essentially a request listener plus a logger processor, with no I/O, persistence, or background workers. There are no migrations or external dependencies to operate. The practical production concerns are trusting inbound headers and pinning the version so a future constraint change does not surprise you.
- What ID generation strategy does it use, UUIDv4 or ULID?
- The package supports configurable ID generation, so the exact default should be confirmed in the bundle configuration and documentation for your installed version. If you need UUIDv4 or ULID consistency across services, configure the generator explicitly instead of relying on the default. Standardizing the format matters when IDs cross service boundaries and appear in logs or traces.
- How do I test that the request ID header and log context are set?
- Use Symfony's test client or kernel browser to make a request and assert that the configured response header is present. For logs, use a test logger or Monolog test handler and assert that the request ID appears in the log context. Also test inbound header propagation and your validation or sanitization rules, since those are the trust-boundary cases.
- What are the alternatives to sbsedv/request-id-bundle in Laravel?
- In Laravel, the simplest alternative is custom middleware that generates or validates a request ID, stores it in context, and adds it to the response. API gateways and service meshes often inject correlation IDs already, which may remove the need for application-level generation. Use this Symfony bundle as a reference behavior if you want one consistent request-ID contract across Symfony and Laravel services.
- Is the package actively maintained and what are the upgrade risks?
- It is a small, single-maintainer project with a limited footprint, and version 1.9.0 is a compatibility release that includes the first external contribution. That is acceptable for a small utility you can vendor-patch if needed, but not ideal for business-critical dependencies. Pin the version, verify Composer constraints, and confirm inbound validation behavior before rolling it out broadly.
Weaver
How can I help you explore Laravel packages today?