Log Subscriber Laravel Package

Technical Evaluation

• Architecture fit: guzzlehttp/log-subscriber is not a Laravel-native package. It is a Guzzle 4/5 event subscriber that logs HTTP requests and responses at the wire level. Modern Laravel uses Guzzle 6/7 through Illuminate\Http\Client, where the old event-subscriber model has been replaced by middleware. Fit is therefore poor for current Laravel and acceptable only in a legacy service already pinned to Guzzle 4/5.
• Integration feasibility: Low for modern Laravel/PHP. Composer constraints will likely conflict with Laravel’s Guzzle 6/7 requirement, and runtime APIs differ even if forced. A modern integration would require isolation in a legacy service, a fork, or a compatibility shim—none of which is attractive for a small logging concern. The supported replacement is Guzzle’s native Middleware::log with MessageFormatter, wired to a PSR-3/Laravel logger.
• Technical risk: High. The package is archived, has only 43 stars and 0 dependents, and has no active maintenance or security response. It captures request/response data that may include credentials, tokens, PII, and large bodies; the package itself does not solve redaction, sampling, size caps, or structured logging. Adopting it creates upgrade debt and blocks Laravel/Guzzle/PHP upgrades.
• Key questions:
  • Which Laravel, PHP, and Guzzle versions are actually in scope?
  • Is any service still on Guzzle 4/5, or is this purely a modern Laravel estate?
  • Is wire-level request/response logging truly required, or would application-level HTTP logging suffice?
  • What are the PII/secret-redaction, retention, sampling, and audit requirements?
  • Does organizational policy permit archived dependencies, and what is the exit plan?
• TPM recommendation: Do not adopt for new development or shared platform use. Approve only as a time-boxed legacy bridge where Guzzle 4/5 already exists, with an explicit replacement plan using native Guzzle middleware.

Integration Approach

• Stack fit: Weak for Laravel 8+ and PHP 8+. Strong fit only for legacy Laravel applications already using Guzzle 4/5. The package has no Laravel service provider, configuration surface, facade, or Laravel-native logging integration; it must be attached to a Guzzle client’s event dispatcher and bridged to Laravel’s logger.
• Preferred replacement: Use GuzzleHttp\Middleware::log() with a HandlerStack and a PSR-3 logger, configured through a centralized HTTP client service provider. In Laravel, route this to a dedicated log channel with redaction, sampling, and body-size limits. Use Laravel’s Guzzle middleware hook where available, or inject a configured Guzzle client into the HTTP layer.
• Migration path: Inventory composer.lock and service code for Guzzle versions and current logging behavior. If no Guzzle 4/5 dependency exists, reject the package. If a legacy dependency exists, isolate the subscriber behind an internal adapter, reproduce the log format with native middleware, add regression tests for headers/bodies/redaction, then remove the archived package before the next framework upgrade.
• Compatibility: Treat the package as Guzzle 4/5-only. Do not assume PHP 8 compatibility even if Composer resolves it; old Guzzle versions may fail at runtime. Modern Laravel versions require newer Guzzle and PHP, so compatibility should be proven with a spike, not assumed.
• Sequencing: 1) confirm versions and business need; 2) obtain policy exception if legacy use is unavoidable; 3) build an isolated proof of concept; 4) implement native Middleware::log as the target state; 5) migrate logging format and redaction; 6) remove guzzlehttp/log-subscriber and add a guardrail preventing reintroduction. Do not place this package in a shared Laravel core dependency.

Operational Impact

• Maintenance: Ownership transfers to the adopting team because upstream is archived. Any bug, PHP compatibility issue, or security concern requires an internal fork or replacement. MIT licensing permits a fork, but the maintenance cost is not justified for a capability already available in supported Guzzle middleware.
• Support: No vendor or community support. Documentation is limited to historical usage. Incident response depends on internal knowledge of Guzzle 4/5 events and Laravel logging adapters. This is a supportability regression compared with native Guzzle middleware.
• Scaling: Wire-level logging can generate high log volume and large payloads. Synchronous logging can add latency to outbound HTTP calls; log ingestion and storage costs can grow quickly. Production use requires sampling, body-size caps, header filtering, async/buffered logging, and retention policies. It is a poor fit for high-throughput API clients without those controls.
• Failure modes: Logger exceptions may propagate into HTTP request paths depending on event dispatch behavior; large bodies can increase memory use; sensitive data can leak into logs; Guzzle upgrades can cause silent non-invocation or fatal class/API errors; Composer conflicts can block upgrades. The most dangerous operational failure is false confidence: teams may believe HTTP logging is active while the subscriber is no longer invoked after a Guzzle migration.
• Ramp-up: Low effort to understand the basic “log request/response” intent, but high effort to operate safely in a legacy stack. Teams need guidance on Guzzle 4/5 events, Laravel log channels, PSR-3 bridging, redaction, sampling, and migration to Middleware::log. A short internal runbook and an explicit removal date are mandatory if a legacy exception is granted.