wieni / wmsentry Goto Github PK

Summary

https://docs.sentry.io/platforms/php/configuration/options/#in-app-include

Description

PHP Deprecated: Method Sentry\Options::setExcludedExceptions() is deprecated since version 2.3 and will be removed in 3.0. Use the "IgnoreErrorsIntegration" integration instead.

Steps to reproduce

Invoke the logger.

$context['ip'] should be checked for emptiness before passing it to $data->setIpAddress()

Description

Sometimes, issues are sent to Sentry multiple times, but in different formats:

First issue

Title: Too few arguments to function Drupal\wmcustom\Menu\MenuBuilder::__construct(), 4 passed in /home/www-mediawijsdev/web/public/core/lib/Drupal/Component/DependencyInjection/Container.php on line 257 and exactly 6 expected
Description: same

Does not have mechanism tag
Has release tag

Second issue

Title: ArgumentCountError
Description: Too few arguments to function Drupal\wmcustom\Menu\MenuBuilder::__construct(), 4 passed in /home/www-mediawijsdev/web/public/core/lib/Drupal/Component/DependencyInjection/Container.php on line 257 and exactly 6 expected

Has mechanism: generic tag
Does not have release tag

Third issue

Same as second, but also has an url.

Summary

Add the possibility to ignore errors using regexes for issues that are hard to ignored using their structured info.

Some examples:

• Deadlock found when trying to get lock
• Lock wait timeout exceeded

Summary

Add PHP 8 support.

TODO

• Change minimum version of sentry/sentry to 3.1.1

Summary

Sentry has a feature called Inbound Filters where you can drop incoming events when the error message matches with a set of patterns you can define. You can provide multiple patterns, one per line. The filter applies if any of the patterns match.

The Inbound Filters feature is paid-only and requires a Sentry business account.
We'd like to replicate that feature to wmsentry to drop events before even sending them, based on the error message.

Currently there is the excluded_exceptions and excluded_tags config option.
We'd like to propose an additional excluded_error_messages.

Basic example

excluded_error_messages:
  - 'The icon * is not available*'
  - 'Email not sent for *'

Summary

This modules supports dropping unwanted logs through the excluded_exceptions and excluded_tags config options.
However, we (Wieni, the web agency) want the possibility to consolidate some exclusions for our entire organization.

For example when we identify a new tag or exception that we want to exclude, we don't want to have to update the wmsentry config in all our projects.
As a workaround we used inbound filters, but that's only available when you have a Business subscription at Sentry. We moved to a Teams subscription so are looking for a new workaround.

Proposal

A new exclusion_remote_config option where you can enter a url to fetch extra exclusion config.

exclusion_remote_config: 'https://s3.eu-central-1.amazonaws.com/org-wmsentry-config/wmsentry.config.yaml'

The content at https://s3.eu-central-1.amazonaws.com/org-wmsentry-config/wmsentry.config.yaml is:

excluded_exceptions:
  - Drupal\my_module\Exception\SomeException
excluded_tags:
  - tag: channel
    value: 'some channel'

If we want to add a new excluded exception to all our projects, we would only need to update the yaml file stored on S3.
Cron will check if the yaml file on s3 has changed and will reconfigure wmsentry if needed.

• Add phpstan.neon config file referencing the wmcodestyle rule files (example)
• Add phpstan analyse to the coding-standards composer script
• Add autoload-dev entry to ensure autoloading during analysis

Summary

https://docs.sentry.io/platforms/php/enriching-events/breadcrumbs/

Summary

This would allow you to eg. log all deprecations, instead of having to log all info level messages if you want to log deprecations. The mapping between PHP & RFC error levels can be found in the drupal_error_levels function.

Summary

Add a simple way to make sure the integration with Sentry is working as it should, without having to manually trigger exceptions and check the Sentry issue queue.

Motivation

Right now, the only way to test whether the integration with Sentry is setup right is to trigger an exception - or to wait until an exception is triggered on some page - and to check if a Sentry issue was created in the right project.