Model Violation Logger Bundle Laravel Package

Technical Evaluation

What it is. Despite the "Laravel/PHP package" framing, rezzza/model-violation-logger-bundle is a Symfony bundle — the Bundle suffix and Rezzza\ vendor namespace reflect the Symfony 2.x DI/plugin model (Rezzza was a Symfony-focused agency). It hooks model validation failures into the logging stack. This is not a Laravel package and has no Laravel integration path; Laravel has no bundle/DI-extension system, so the code cannot be installed and used as-is.

Architecture fit. Poor as a dependency. The functional intent — capturing which validation rules fail, on which fields, how often — is legitimate and useful (client-error telemetry, form-funnel analytics, input-contract drift detection). But the implementation is bound to a framework we do not run, and the pattern is genuinely small: in Laravel this is a listener on Illuminate\Validation\ValidationException (or a FormRequest::failedValidation override) plus a log/table sink — roughly 50–150 lines. The package's own surface area is similarly small, which is why it was never widely adopted.

Integration feasibility. Near zero for direct adoption:

• Wrong framework (Symfony bundle ≠ Laravel service provider).
• Last release 2015-01-08 — predates PHP 7, PSR-4 consolidation, Symfony 3/4/5/6, and modern Monolog handler APIs. It will almost certainly declare PHP 5.x / Symfony ~2.x constraints and fail composer install on any current runtime.
• 4 stars, 0 dependents, score 0.24. No production signal anywhere. This is not a dependency; it is a historical artifact.

Technical risk. High and asymmetric. There is no upstream maintainer, no security response, no CI, and no compatibility contract. Vendoring it means owning a permanent fork whose only benefit is reusing ~100 lines of PHP 5-era glue. The residual value is conceptual, not code.

Key questions to resolve before spending any further effort:

1. What is the actual requirement — validation-failure observability, user-facing error analytics, or audit logging? Each has a different, cheaper native implementation.
2. Are we on Laravel or Symfony? If Symfony, is it 5.4/6.x/7.x? The bundle is still incompatible either way.
3. Does the log payload include user-submitted values (PII/PCI)? A 2015 validation logger almost certainly does not redact.
4. Is there any reason to prefer a port over a greenfield listener? (Expected answer: no.)

Recommendation: Do not adopt. Treat the repository as a reference design for the log record shape (violations per model/field/rule) and reimplement natively.

Integration Approach

Stack fit. Assume a Laravel application. The Symfony bundle is out of scope entirely; the equivalent is a first-party module inside our own codebase, not a Composer dependency.

Migration path (port, don't install).

1. Read-and-discard. Spend ≤1 hour skimming the bundle's violation-capture logic and log schema; extract the field taxonomy (model, attribute, rule, message, timestamp, request correlation) rather than the code.
2. Native listener. Register a listener/subscriber on ValidationException (and optionally QueryException/ModelNotFoundException) that emits a structured record to a dedicated channel — never the default application log.
3. Sink. Start with a rotating file channel or a validation_violations table; promote to the existing observability pipeline (Monolog handler → Loki/CloudWatch/Datadog) if volume justifies it.
4. Redaction gate. Whitelist fields (attribute name, rule name, model class); never log raw input values unless explicitly approved.
5. Delete the fork. If anyone has already forked the bundle, retire it in the same change.

If the estate is genuinely Symfony. Verify the runtime version first. A 2015 bundle will not survive Symfony 5+. Even there, the correct move is a small EventSubscriber on the validator event plus a PSR-3 logger — not a revived abandoned bundle.

Compatibility. Target the PHP version and framework LTS we actually run; the package's constraints (PHP 5.x-era, Symfony 2.x) are incompatible with any supported runtime today. Do not attempt a "modernize the fork" track — it converts a 100-line feature into a maintained package with a maintainer on-call.

Sequencing. (a) Confirm the requirement and owners, (b) spike the native listener in one service, (c) measure volume and cost, (d) decide on file vs. table vs. telemetry sink, (e) roll out behind a config flag, (f) document retention and redaction. Total effort: days, not sprints.

Operational Impact

Maintenance. Native code is a few dozen lines inside our own repo, covered by our framework upgrade tests. The abandoned bundle would be a permanent liability: no patches, no CVE response, and a hard blocker at the next major framework upgrade. At 0 dependents and 4 stars, there is no community to absorb that cost — it would be entirely ours.

Support. No upstream issue triage, no maintainer, no release cadence since January 2015. Internal support would rest on whoever wrote the fork, with no external escalation path. Ramp-up on the codebase itself is trivial (small, PHP 5-era, lightly structured), but that knowledge has no reuse value and evaporates with the engineer.

Scaling. The design concern is volume, not throughput: validation failures can be high-cardinality and high-frequency (bots, malformed clients, fuzzing). Unbounded logging will dominate storage cost and create noise that buries real signal. Mitigate with sampling, per-route rate limits, and aggregation on (model, attribute, rule) rather than raw event retention. The package offers no such controls.

Failure modes.

• Silent no-op after framework upgrade — the listener stops firing and nobody notices until the metrics are missed.
• PII leakage — 2015-era code predates routine redaction; raw submitted values in logs is a compliance incident waiting to happen.
• Log-volume incident — a malformed client or scanner floods the channel; if it shares the application log, it can mask production errors.
• Alert fatigue — validation violations are overwhelmingly client bugs, not server faults; routing them into the error channel will degrade on-call signal quality.
• Recursive failure — logging inside a validation path that itself throws (large payloads, encoding errors) can mask the original exception.

Ramp-up. Effectively zero for the recommended path: any mid-level Laravel engineer can implement and own this in a day. The only genuine cost is the governance work — deciding what may be logged, for how long, and who reads it. That work is required regardless of whether the code comes from a 2015 bundle or from our own repository, and it is the only part of this evaluation that carries real product weight.