Is it possible to register callback, like this for example: https://docs.bugsnag.com/platforms/php/symfony/customizing-error-reports/ ...from service container? Like:

# services.yml
bugsnag.callbacks.custom_one:
    class: AppBundle\Extensions\Bugsnag\CustomOne
    tags:
        - { name: bugsnag.callback }

How about it?

Hi all, a minor suggestion, with friendly reference to https://github.com/evolution7/Evolution7BugsnagBundle/blob/master/EventListener/Exception/HttpKernelListener.php#L45-L47

Expected behavior

4** range errors should not trigger error notifications, since these types of Exceptions are handled via Symfony and not logged as error.

Observed behavior

4** range errors trigger error notifications

Steps to reproduce

Request a non-existing URL or otherwise trigger a 403/401 error and receive an error notification

Version

1.5.0

Additional information

I understand this behavior can be suppressed by registering a custom callback, but out of the box I imagine most people, including Bugsnag operators, would like to suppress a flood of 404 reports, which other solutions are more adept at monitoring.

Thank you for your time.

Adds support for and an example of Symfony 4.

Note: While the library itself doesn't need updating, the methods of using services has changed with Symfony 4, and the docs will require thought put in to how to reflect this.

For now the example README contains an updated guide on integration.

As we are sometimes experiencing longer response times from our Bugsnag servers it would be great to configure a timeout on the used Guzzle Connection.

Currently this does not seem to be possible.

I got a deprecated error when using bugsnag-symfony with PHP 8.1 :

stripos(): Passing null to parameter #1 ($haystack) of type string is deprecated in vendor/bugsnag/bugsnag-symfony/Request/SymfonyRequest.php line 104

This is my first PR, so please tell me if something is not right.

Goal

Make bugsnag-symfony compatible with PHP 8.1.

Changeset

It checks that $haystack is not null before using stripos()

Testing

I ran phpunit tests

Describe the bug

Attempted to call an undefined method named "getUsername" of class "App\Entity\User" on bugsnag/bugsnag-symfony v1.11.0 There cannot be getUsername() method because it was changed to getUserIdentifier() method in Symfony 5.3

Environment

• Bugsnag version: 3.26.1
• PHP version: 8.1
• Symfony version: 6.0

Error:

Fatal error: Uncaught Error: Call to undefined method App\Entity\User::getUsername() in .../vendor/bugsnag/bugsnag-symfony/DependencyInjection/ClientFactory.php on line 392

Goal

Provide a very simple way to extend an exception with additional meta data everywhere without further dependencies.

Design

This feature is very pragmatic and straightforward. Similar to PSR Logger, we provide a MetaDataAwareInterface and a MetaDataAwareTrait. The developer can (but must not) extend his Exceptions with the Interface / Trait to add some additional informations:

class UnrecoverableProcessException extends Exception implements MetaDataAwareInterface
{
    use MetaDataAwareTrait;
}

Later just pass your informations:

$exception = new UnrecoverableProcessException('I am an Exception');
$exception->addMetaData(['myTab' => [
    'foo' => 'bar',
]]);

throw $exception;

This implementation does not need any services or heavy structures.

Changeset

Added

• MetaDataAwareInterface
• MetaDataAwareTrait

Changed

• BugsnagListener add MetaData if Exception implements interface

Tests

I have added automatic tests (with and without meta data)

Review

For the submitter, initial self-review:

• [x] Commented on code changes inline explain the reasoning behind the approach
• [x] Reviewed the test cases added for completeness and possible points for discussion
• [x] A changelog entry was added for the goal of this pull request
• [x] Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • [ ] Initial review of the intended approach, not yet feature complete
  • [ ] Structural review of the classes, functions, and properties modified
  • [x] Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• [ ] Consistency across platforms for structures or concepts added or modified
• [ ] Consistency between the changeset and the goal stated above
• [ ] Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• [ ] Usage friction - is the proposed change in usage cumbersome or complicated?
• [ ] Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• [ ] Concurrency concerns - if components are accessed asynchronously, what issues will arise
• [ ] Thoroughness of added tests and any missing edge cases
• [ ] Idiomatic use of the language

This bundle currently reports all http exceptions, even though they are caught and converted into 4xx-level pages by the symfony framework. See: https://github.com/bugsnag/bugsnag-symfony/issues/67

This PR adds a configuration parameter to disable reporting http errors. It defaults to false to preserve current behavior for BC reasons.

Goal

Provide a way to filter out some exception from report according to project-specific needs.

Design

This approach uses a simple Strategy pattern to handle all possible cases with little cost. A default implementation is provided to keep the current behavior : report all exceptions.

Changeset

Added

• ErrorNotifyFilter
• DefaultErrorNotifyFilter

Changed

• BugsnagListener & Configuration
• services.yml

Tests

Existing tests was updated to fit current behavior. A new test was added to test the new behavior.

Linked issues

This is related to #67 but with a higher view.

Review

For the submitter, initial self-review:

• [x] Commented on code changes inline explain the reasoning behind the approach
• [x] Reviewed the test cases added for completeness and possible points for discussion
• [x] Check the scope of the changeset - is everything in the diff required for the pull request?
• [x] A changelog entry was added for the goal of this pull request
• This pull request is ready for:
  • [x] Initial review of the intended approach, not yet feature complete
  • [x] Structural review of the classes, functions, and properties modified
  • [ ] Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• [ ] Consistency across platforms for structures or concepts added or modified
• [ ] Consistency between the changeset and the goal stated above
• [ ] Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• [ ] Usage friction - is the proposed change in usage cumbersome or complicated?
• [ ] Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• [ ] Concurrency concerns - if components are accessed asynchronously, what issues will arise
• [ ] Thoroughness of added tests and any missing edge cases
• [ ] Idiomatic use of the language

Ref #91

Two things were needed:

• bypass the removal of the root_dir parameter and use the project_dir if available (a new parameter bugsnag.symfony_root was added);
• add support for the new event classes.

I kept support for Symfony < 5 and Symfony >= 5.0 at the same time. I also added CI build for PHP 7.2 and PHP 7.3.

I also added an example application for Symfony 5.0.

Expected behavior

Exceptions thrown in MessageHandlerInterface are catched by the BugsnagListener.

Observed behavior

This isn't the case.

Steps to reproduce

Have a MessageHandlerInterface throw an exception.

Version

• bugsnag/bugsnag v3.18.0
• bugsnag/bugsnag-symfony v1.5.1

I suspect all versions are impacted though.

Additional information

Every exception thrown inside a message handler is catched by the worker so it can continue working so there is no kernel.exception. Instead a WorkerMessageFailedEvent is dispatched so the BugsnagListener should also listen to it.

Description

I maintain Acquia CLI, a Symfony Console application. I can't figure out how to report exceptions to Bugsnag via this library.

Many libraries similar to Bugsnag, such as Amplitude, support a singleton pattern of interaction, i.e. Bugsnag::getInstance()->notifyException(new Exception()) as opposed to $this->get('bugsnag')->notifyException(new Exception()).

The singleton pattern is a lot easier (possibly, the only way) to integrate with Symfony Console applications, which are really stripped down from a full Symfony app. For instance, I don't even know what $this or get() referenced above are supposed to refer to. In a console app, assuming you are throwing an exception from a Command (usually the case), $this would be an instance of \Symfony\Component\Console\Command\Command and it would have no such method get(). I assume this is something to do with the service container or framework bundle, which generally shouldn't / can't be accessed directly in CLI apps.

We also throw a custom AcquiaCliException and we'd really love to report to bugsnag from within that exception. Since it extends \Exception, it has no access to Symfony resources. +1 to using the singleton pattern here.

Finally, I'm not sure if Console apps support bundles, I suspect not, which means that autoreporting uncaught exceptions won't work either.

Describe the solution you'd like

Guidance on how to integrate with Console apps, via a singleton pattern or some other method.

Description

The Symfony bundle does not seem to provide a way to configure the auto_capture_sessions option. The Laravel integration does provide this.

Describe the solution you'd like

It would be nice if this could be configured through the bundle configuration.

Describe alternatives you've considered

Currently I set this manually after loading the bundle and configuration in our Symfony kernel.

First off, this bundle has come a long way and I really like it now, great job, and thank you!

One snag I ran into though:

Expected behavior

According to the documentation I can configure this bundle via ENV vars, specifically, setting BUGSNAG_API_KEY – the idea of ENV vars being that I can change their values during deploy time to produce different runtime behavior.

Observed behavior

However, by default ENV vars only end up as a default-values to the container build step, and are consequently frozen into the container as resolved value. A change to ENV vars will not affect a change to the runtime configuration, without rebuilding the container. See: https://github.com/bugsnag/bugsnag-symfony/blob/master/DependencyInjection/Configuration.php#L26

Steps to reproduce

1. Warm the cache (build container) while providing BUGSNAG_API_KEY via ENV var.
2. Start a webserver hosting the bundle with a different ENV setting.
3. Trigger error report & observe it going to the build-time account. Alternatively, look into the cached container and find frozen resolved value.

Version

1.5.0

Additional information

By explicitly specifying the api_key via ENV var, the bundle remains configurable at runtime:

bugsnag:
    api_key: "%env(BUGSNAG_API_KEY)%"

My recommendation would be to avoid setting default values via ENV inside the Configuration class and instead require them to be specified inside the bugsnag.yml config file.

This is my attempt at resolving issue #35.

This PR enables custom callbacks to be registered to the Bugsnag Client object, by creating a service and tagging it with the bugsnag.callback name.

The service must implement a registerCallback method, which is used in the same way as the registerCallback method on the Bugsnag client. This method name is definable on a per-service basis, by setting the method attribute on the tag.

I have also re-factored the existing user setting code in ClientFactory to be a callback service included in the bundle.

I have made additions to the example apps in the repo to show an example callback service, but have not written any documentation for the new feature as they seem to live separately.

@PReimers - does this implementation solve your use case?