Introduce PSR-14 Event for Intercepting and Modifying Data Sent to Sentry #114
Conversation
| new BeforeSentryCaptureEvent($exception) | ||
| ); | ||
|
|
||
| if (!$event->isPropagationStopped()) { |
There was a problem hiding this comment.
IMHO isPropagationStopped() check is used wrong here: the event dispatcher takes care to check if other listeners in the queue should be called (isPropagationStopped() returns true). You use this to avoid the sending of exceptions to Sentry - which is wrong IMHO.
There may be valid use cases in an installation to define two event listeners where the first one says: I am the one, the second shouldn't be called - then modifies the exception for storage in Sentry and sets propagation stopped - and in your implementation the exception is not send to Sentry altogether. Think of an extension plugin which has a token (person-referenced) in a URL or a user id which the appropriate listener want to obfuscate. Other listeners are not needed to be called therefore.
So, I suggest to decouple that and introduce a separate method to disable the sending of exceptions. Maybe the implementation of the stoppable interface is not needed altogether and can be removed.
|
You can register a custom Integration within |
3 participants
This pull request introduces a PSR-14 event within the extension. This allows developers to intercept the data being prepared for transmission to Sentry, enabling them to prevent specific data from being sent or to modify the exception information before it reaches the Sentry service.