Exception Enricher Laravel Package

Product Decisions This Supports

• Incident response and on-call quality (MTTR). Capturing POST bodies at WARNING and above means the failing request payload is already in the log when checkout, auth, or integration calls break — support and on-call can reconstruct the failure without a reproduction session or a customer call. This is a direct input to whether we invest in "reproducible-by-default" production debuggability or keep paying for it in escalation time.
• Data classification and logging policy. The release makes an explicit policy stance: no bodies at INFO/DEBUG, secrets masked by field name (password, token, jwt, secret, authorization, api_key, credential) across form, JSON (including BOM), and urlencoded bodies, nested and inside lists. That is a decision we can adopt as our default logging standard rather than writing one, but it also sets the ceiling of what our policy covers — field names outside that list (SSN, card number, CVV, IBAN, DOB, medical record IDs) are not masked. This needs a privacy/legal sign-off decision, not an engineering one.
• Fail-closed vs forensic completeness trade-off. Bodies that cannot be masked (undecodable JSON, XML/text containing a secret word) are dropped entirely. That is the safer default and the right call for most B2C traffic, but it means SOAP/XML/legacy payloads produce no body on failure. If a material revenue path runs on XML, that is a product-level gap to accept knowingly.
• Observability spend and retention. Removing bodies from INFO/DEBUG and truncating at 2048 characters bounds both log volume and per-record size — a direct lever on storage, SIEM ingest, and egress cost. This is one of the few observability changes that improves debuggability and reduces spend, which makes it unusually easy to justify.
• Platform currency roadmap. PHP 8.3 minimum, Symfony 6.4 / 7.4 / 8.1, and a fix for Symfony 8 bundle loading plus removal of the hidden symfony/yaml dependency. Adopting this pulls the PHP-upgrade conversation forward; if we are on PHP 8.1/8.2 or Symfony 5.4, the real decision is the upgrade, not the package.
• Build vs buy on logging instrumentation. Correct secret masking is deceptively hard — BOM-prefixed JSON, nested objects, arrays, urlencoded bodies, whole-value masking of containers. An in-house Monolog processor gets the common cases right and the edge cases wrong, and wrong here means credentials in a log aggregator. This is a strong argument for consuming maintained code rather than writing our own.
• Standardization across services. If it holds up, this is a candidate default for request-context logging across the fleet, which reduces per-team bespoke logging code and makes cross-service incident triage consistent.

When to Consider This Package

Consider adopting when:

• The application is Symfony 6.4, 7.4, or 8.1 on PHP 8.3+, already logging through Monolog, and wants request context attached without custom processors.
• Production debuggability of failed write operations is a recurring pain point (support tickets, "cannot reproduce", long escalations).
• Privacy/security will accept name-based masking as a control, and we can enumerate our sensitive field names against the default list and extend or restrict accordingly.
• We want lower log volume at INFO/DEBUG without losing the ability to see who and what URI triggered a request.
• We prefer a maintained dependency over an in-house processor for the masking logic.

Look elsewhere or validate first when:

• The stack is Laravel. The release notes describe Symfony bundle wiring (services.php, Symfony 8 : void signature), not a Laravel service provider. If our codebase is Laravel, confirm a maintained integration exists or expect adapter work; a Laravel-native logging package may be the better fit. This is the first thing to verify.
• Regulated data flows through fields whose names are outside the default secret list, and we cannot guarantee naming discipline across teams.
• The primary failing payloads are XML/SOAP or non-JSON text — those get dropped, so the feature delivers no value on that path.
• Full, untruncated payloads are required for forensics or dispute resolution; 2048 characters will cut off large forms and JSON blobs.
• We are on PHP < 8.3, Symfony < 6.4, or have no near-term plan to move.
• Traffic is high-volume enough that WARNING-level bodies are themselves a storage or SIEM cost concern, or a per-tenant/per-region redaction policy is required — name-based masking is not a policy engine.

Evidence gaps to close before an ADR: this assessment is based on a single release's notes. License, maintainer depth and bus factor, test coverage of the masking paths, existing adoption, and issue responsiveness are all unknown. Pull the repo, read the masking tests, and check the changelog history before committing.

How to Pitch It (Stakeholders)

To executives: One paragraph — this is a small, low-cost logging component that makes production failures diagnosable from the log alone, cuts log storage and SIEM ingest by dropping request bodies from routine INFO/DEBUG traffic, and ships with credential masking and hard size caps on by default so we are not writing customer secrets into our log platform. It also keeps us on currently supported PHP and Symfony versions, which reduces security-patch risk. The ask is an engineering day plus a privacy review, not a budget line.

To engineering: Drop-in request-context capture for Monolog. Bodies at WARNING+ only, capped at 2048 characters with an explicit truncation marker so you know you're missing data rather than silently guessing. Masking covers form, JSON (BOM-safe), and urlencoded bodies, nested and in lists, matching on field names and substrings of field names. Unmaskable bodies are dropped rather than logged raw. Symfony 8 loading bug fixed, symfony/yaml no longer a hidden dependency, PHP 8.3+.

To security, legal, and compliance: The defaults are conservative and fail closed: no bodies below WARNING, secrets replaced with *** as whole values (including inside objects and arrays), and anything we cannot confidently mask is omitted. Two things need your explicit sign-off: (1) masking is name-based, so our field-naming conventions are the control — we should confirm the list covers our regulated fields or extend it; (2) WARNING-level records will contain customer-submitted data, so retention and access controls on the log store become in-scope for the privacy review.

Before we sign off: confirm the Laravel-vs-Symfony integration story, review the masking test suite, run a red-team pass with our own field names, and confirm log retention policy covers WARNING-level payloads.