Weave Code
Reporter Bundle Laravel Package
php-bug-catcher/reporter-bundle
A Symfony bundle for php-bug-catcher that wires up automatic exception and error reporting, capturing detailed bug reports and sending them to your configured reporter so you can find and fix issues faster.
Exception and gug lsymfony logger
Frequently asked questions about Reporter Bundle
- How do I install php-bug-catcher/reporter-bundle in a Laravel application?
- Install it with composer require php-bug-catcher/reporter-bundle; Laravel package auto-discovery registers the service provider, so you typically only publish the config file and set your reporter endpoint and key. On Symfony you register the bundle in config/bundles.php instead. Finish by throwing a deliberate exception in staging and confirming the report lands in your Bug Catcher instance before enabling it in production.
- Which Laravel and PHP versions are supported, and should I pin the package version?
- The bundle hooks Laravel's exception handling and Monolog, so it works on any Laravel release that still exposes those extension points; check the composer.json constraints for the exact PHP and illuminate/support ranges before upgrading. Pin an explicit version such as 2.1.1 rather than relying on a caret range if you need reproducible fleet rollouts. Upgrade in staging first, then ship with your normal deploy mechanism.
- How does the bundle capture exceptions and errors automatically?
- It registers listeners around the framework's error handling, so exceptions and errors are caught without wrapping your own try/catch blocks. In Laravel this is a write-stack-trace listener plus a Monolog handler; in Symfony it is kernel listeners. Each captured event carries the stack trace, request data, user info and environment, which is then forwarded to your configured reporter.
- Can I filter which exceptions get reported or ignore noisy ones?
- Yes. The bundle exposes configurable reporting levels and ignore rules so you can drop expected exceptions, third-party noise and low-severity errors before they leave the process. Tune these early, because report volume directly affects collector quota and the signal-to-noise ratio your team actually reads.
- Does the reporter slow down my app or risk breaking production?
- Reporting is designed to be non-blocking and lightweight, and it adds no queue, daemon or new infrastructure. The main thing to verify is the code-window extraction: the new frame builder reads source from disk at throw time, so on stripped or opcache-only container images it must fail soft. A throw inside the exception handler would mask the original error, which is the worst possible failure mode for a reporter, so test that path explicitly.
- What is the serialize() payload format and why should I care?
- Reports are sent as PHP serialize() output of a codeframe array, which only works because both the client and the Bug Catcher server are PHP. That forecloses non-PHP consumers, makes payloads hard to inspect in transit and awkward to diff in a log pipeline. It is fine for a PHP-only estate but a real blocker if you ever want to route reports through anything else.
- Can I self-host the Bug Catcher server, and what does running it involve?
- Yes, the collector is a separate package, php-bug-catcher/bug-catcher, which you deploy and operate yourself. That means you own TLS and authentication on the ingest endpoint, retention and scrubbing policy, upgrades and capacity planning. Treat the staffing question as part of the evaluation, not a footnote, especially given unserialize() runs on the receiving end.
- Does the reporter send sensitive data like user info and exception messages?
- It captures request details, user context, environment, stack traces and, after the getPrevious() chain support, the messages of chained exceptions as well. Those chained messages can contain SQLSTATE codes, query fragments or other PII, and they also increase payload size per report. Confirm you have message scrubbing and a retention policy covering the newly captured previous chain, and make sure the ingest endpoint is authenticated and encrypted.
- How do I test the integration without flooding production with fake reports?
- Point the package at a local or staging Bug Catcher instance and disable reporting in your testing environment so your suite never ships fake exceptions. Trigger a deliberate exception, ideally a chained one, and assert that the reported frames point at the throw site rather than the caller. Verify a 5-deep exception chain against any request-body limits on the collector before you go live.
- How does this compare to Sentry, Flare or Bugsnag?
- It occupies the same observability slot, so judge it on capture fidelity, payload cost, failure isolation and self-hosting burden. The upside is a self-hosted, PHP-native stack with no per-seat vendor bill; the trade-offs are that you operate the server and the serialize() wire format limits interoperability. If you are replacing a commercial reporter, run both in parallel until you have confirmed the captured traces are at least as accurate.
Weaver
How can I help you explore Laravel packages today?