Log Bundle Laravel Package

Technical Evaluation

Architecture fit — the core mismatch. etsglobal/log-bundle is a Symfony bundle, not a Laravel package. The README registration path (config/Bundles.php, app/AppKernel.php) and the class ETSGlobalLogBundle presuppose Symfony's HttpKernel, its DI container, Monolog handler wiring through monolog.handler.* tags, and Symfony's event system. Laravel has no bundle concept, no Kernel::registerBundles(), and its logging surface is Illuminate\Log\LogManager over Monolog channels configured in config/logging.php. There is no service provider, no facade, no auto-discovery entry. Any adoption inside a Laravel codebase is a port, not an install.

What is actually valuable here. The feature set is a coherent, opinionated correlation-ID design worth copying even if the code is never installed:

• Automatic logger injection (constructor injection without per-class wiring).
• TokenCollection — a propagating trace token set intended to follow a request from app to app.
• Automatic global and process token lifecycle for inbound HTTP requests/responses and long-running processes (workers/daemons).
• Log context enrichment with app_name plus tokens on every record.
• A Monolog processor that re-levels expected exceptions (e.g. NotFoundHttpException downgraded from error to info) — high value for signal-to-noise ratio.
• Extended Slack handler with custom formatting and filters.
• Guzzle middleware and a Symfony HttpClient decorator for outbound token forwarding.

That is essentially a bespoke, pre-OpenTelemetry tracing layer. Modern equivalents (W3C traceparent, OpenTelemetry PHP, Laravel 11's Context facade) cover most of it with vendor-neutral semantics.

Integration feasibility: low-to-moderate, and mostly by extraction rather than consumption.

• The Guzzle middleware and TokenCollection are plausibly framework-agnostic and could be lifted standalone.
• The listeners, DI compiler passes, Monolog handler tags, and HttpClient decorator are Symfony-bound and will not run under Laravel.
• Composer-level conflict is a realistic blocker: an ETSGlobal internal bundle from the Symfony 3.4/4.x era will likely pin Monolog 1.x/2.x and PHP ≤8.0, while Laravel 10/11/12 ship Monolog 3 and PHP 8.1+. Monolog's SlackHandler/SlackWebhookHandler constructor signatures changed materially across those majors, so the "extended Slack handler" is the most fragile piece.

Technical risk: high, driven by provenance, not code quality.

• Zero stars, zero dependents, no external consumers. This is internal ETSGlobal tooling published to Packagist. There is no community to surface bugs, no downstream compatibility canary, and no evidence of external use in production.
• Travis CI badge. Travis is effectively defunct for OSS; the badge is a stale signal, not evidence of a live pipeline.
• Score 14.3/100 with opportunity 25.32 — consistent with a single-vendor utility with no adoption.
• Bus factor of one team. No SLA, no security disclosure process, no changelog discipline evidenced beyond "releases."
• Long-running-process token handling is the highest-risk design point. Token propagation via a shared/static collection is exactly the pattern that leaks correlation IDs across requests under Laravel Octane, Swoole, or queue workers unless reset per unit of work.
• Inbound token trust. If tokens are accepted verbatim from client-supplied headers and injected into log context, you inherit log-injection and unbounded-cardinality risk in your logging backend.

Key questions to resolve before any commitment:

1. What PHP, Symfony, and Monolog version constraints does composer.json declare, and does it install cleanly alongside our Laravel and Monolog major?
2. Is TokenCollection static/singleton state, or request-scoped? What resets it between requests and between queue jobs?
3. What are the exact header names, and are they compatible with W3C traceparent or a de facto standard (X-Request-Id)?
4. Does it hard-require symfony/http-client, and would that pull a parallel HTTP stack into a Guzzle-based Laravel app?
5. Are tokens propagated into async work (queues, scheduled jobs), or does the trace chain break at the first dispatch?
6. Is the Slack handler synchronous on the request path? What are its timeout, retry, and failure-isolation behaviour?
7. Who owns the repository, what is the release cadence, and are we permitted to fork and vendor it?
8. Does the exception-leveling processor hardcode Symfony exception classes (NotFoundHttpException) with no Laravel mapping hook?

Integration Approach

Stack fit: do not install; reimplement the contract. The bundle's value is its design decisions, not its Symfony plumbing. A Laravel-native equivalent is roughly 200–400 lines and removes every dependency and lifecycle risk above. Recommended posture: treat this repository as a reference implementation and design document, and cite it as prior art in the ADR rather than as a dependency.

If a direct dependency is mandated, contain it. Restrict adoption to the framework-agnostic surface — TokenCollection plus the Guzzle middleware — pulled in as a vendored/forked subtree. Do not register the bundle, do not rely on its Monolog processors, and do not use its Slack handler. Wrap the extracted pieces behind our own interfaces so they can be replaced by OpenTelemetry later without touching call sites.

Migration path (phased, ~3 sprints for a mid-size app):

1. Define the correlation contract first, independent of any library. Fix header names (X-Request-Id, X-Global-Token, X-Process-Token, or align to traceparent), the token format, max length, and the trust boundary for client-supplied values. This is the durable decision; everything else is implementation detail.
2. Inbound capture. Laravel middleware that reads/validates the headers, generates a token when absent, and pushes app_name + tokens into Log::withContext() (Laravel 11+ Context) and into a request-scoped TokenStore singleton.
3. Outbound propagation. A Guzzle middleware registered on the shared client — the direct analogue of the bundle's Guzzle middleware — plus Http::withHeaders() defaults so Illuminate\Support\Facades\Http inherits it.
4. Expected-exception leveling. Implement in bootstrap/app.php withExceptions() or a Monolog processor, mapping ModelNotFoundException/NotFoundHttpException to warning, auth failures to notice. This is the single highest-ROI feature ported from the bundle.
5. Slack handler. Use Monolog's SlackWebhookHandler wrapped in FingersCrossedHandler and a BufferHandler/queued job rather than the bundle's handler. Keep the custom formatter concept, drop the code.
6. Async propagation. Serialize tokens into queue job payloads via a job middleware; reset the TokenStore on JobProcessing and in Octane's request-reset listener. This is where the original bundle is weakest and where we must exceed it.

Compatibility work to schedule explicitly: a Composer dry-run probe (composer require --dry-run) against the target Laravel major, a PHP 8.2/8.3 matrix run, and a decision record on whether Monolog 3's handler signatures invalidate the Slack and processor components. Assume they do.

Sequencing rationale: contract → inbound → outbound → leveling → notifications → async. Each phase is independently shippable and observable, and phases 1–3 deliver the majority of the tracing value without touching logging configuration risk.

Operational Impact

Maintenance. Effectively fork-and-own. With zero external dependents, upstream will not be exercised by anyone but ETSGlobal's own applications, and our issues will not be prioritized. Budget for a named owner plus a periodic upstream diff review. If we vendor, pin to a commit SHA rather than a version range — the 2026-03-20 release date alongside a Travis badge suggests irregular, unversioned publishing cadence.

Support. No SLA, no documented upgrade guide, no security policy. Escalation path is a GitHub issue on a repository with no visible community. Treat support cost as internal, not vendor-provided.

Scaling. Header propagation itself is negligible — a few dozen bytes per hop. The real scaling risks are elsewhere:

• Slack handler is a synchronous outbound HTTPS call. On the request path this adds latency and couples error handling to Slack's availability and rate limits (1 msg/sec/channel). Must be buffered, FingersCrossed-gated, or moved to a queued job. Never allow it to throw into the request lifecycle.
• Log volume amplification. Enriching every record with three tokens plus app_name increases index cardinality; token-per-request fields are fine for filtering but must not become high-cardinality metric labels.
• Long-running processes. The bundle claims explicit support for process token tracing in daemons — good intent, but under Octane/queue workers we must verify reset semantics ourselves. The failure mode is silent cross-request contamination, which is worse than no tracing.

Failure modes to design against:

Ramp-up. Low for engineers with Symfony DI experience — the README plus source is sufficient. Medium for a Laravel-only team, because the bundle's mental model (container compiler passes, tagged handlers, kernel listeners) does not transfer, and engineers will spend more time understanding Symfony wiring than the logging behaviour itself. Budget half a day of onboarding for the concepts and a day for the Laravel-native port.

Strategic recommendation. Score 14.3/100, 0 stars, 0 dependents is a clear signal: do not add this as a runtime dependency. Adopt the correlation-ID and exception-leveling patterns into a small in-house Laravel package, and set OpenTelemetry (or at minimum traceparent alignment) as the forward path so the correlation contract survives the next tooling change. If the organization already runs Symfony services on this bundle, the correct TPM move is a cross-team correlation-contract standard — including queue and scheduled-job propagation — that both the Symfony and Laravel sides implement independently.