[GH-ISSUE #1275] Add feature - Avoid monolog sending email programatically #526

New issue

Closed

opened 2026-03-04 02:15:44 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 02:15:44 +03:00

Owner

Originally created by @LaurentMarquet on GitHub (Jan 7, 2019).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1275

As stated in https://stackoverflow.com/questions/53923774/how-to-avoid-monolog-sending-email-programatically, it seems that is NOT possible to stop Monolog sending email programmatically. We can setup the error level for which we want to send emails, we can update the Response but I haven't found any way to make Monolog to stop sending an email for specific reasons.
What I am looking for is a kind of stopPropagation (this can be done on the event but then it stops the Exception) just for the email.

I have a set of urls that I know they are called and throw an Exception, but I don't want to receive an email. This set of urls is stored in bdd so I cannot set them in a kind of config.yml.

Don't know where to begin to make an eventual PR.

Originally created by @LaurentMarquet on GitHub (Jan 7, 2019). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1275 As stated in https://stackoverflow.com/questions/53923774/how-to-avoid-monolog-sending-email-programatically, it seems that is NOT possible to stop Monolog sending email programmatically. We can setup the error level for which we want to send emails, we can update the Response but I haven't found any way to make Monolog to stop sending an email for specific reasons. What I am looking for is a kind of `stopPropagation` (this can be done on the event but then it stops the Exception) just for the email. I have a set of urls that I know they are called and throw an Exception, but I don't want to receive an email. This set of urls is stored in bdd so I cannot set them in a kind of `config.yml`. Don't know where to begin to make an eventual PR.

kerem closed this issue

2026-03-04 02:15:44 +03:00

kerem commented

2026-03-04 02:15:45 +03:00

Author

Owner

@Seldaek commented on GitHub (Jul 1, 2019):

This is IMO about composing the handler chain correctly. You can wrap the mailer handler with a FingersCrossedHandler for example that has a custom activation strategy set which will look at the request and not trigger for those routes.. Or you could write a custom handler that filters the messages based on whatever. Endless possibilities, but for custom needs you need a little bit of custom code.

@Seldaek commented on GitHub (Jul 1, 2019): This is IMO about composing the handler chain correctly. You can wrap the mailer handler with a FingersCrossedHandler for example that has a custom activation strategy set which will look at the request and not trigger for those routes.. Or you could write a custom handler that filters the messages based on whatever. Endless possibilities, but for custom needs you need a little bit of custom code.

kerem commented

2026-03-04 02:15:45 +03:00

Author

Owner

@LaurentMarquet commented on GitHub (Jul 2, 2019):

Thanks about your answer. I'm not against custom code as I did a bundle, but I have to understand how and what to do, and here I don't...
The thing is that the routes are unknown as stored in a database, when they are found in the database the process in monolog has already started and it seems that I can't stop it. I haven't found any way to say to monolog (event or whatever), don't go further. Moreover, I would like to integrate it in the bundle and not in the configuration of the app, as the goal is to work as is, not to add configuration.
But thanks again for your answer, and the work you provide to OSS.

@LaurentMarquet commented on GitHub (Jul 2, 2019): Thanks about your answer. I'm not against custom code as I did a bundle, but I have to understand how and what to do, and here I don't... The thing is that the routes are unknown as stored in a database, when they are found in the database the process in monolog has already started and it seems that I can't stop it. I haven't found any way to say to monolog (event or whatever), don't go further. Moreover, I would like to integrate it in the bundle and not in the configuration of the app, as the goal is to work as is, not to add configuration. But thanks again for your answer, and the work you provide to OSS.

kerem commented

2026-03-04 02:15:45 +03:00

Author

Owner

@Seldaek commented on GitHub (Jul 2, 2019):

Well I don't know enough about your project to really say, but it sounds to me like you could tell your custom handler to not go further whenever you have your route information. Or to wait/buffer until you have the route info and then tell it to start forwarding log records to the handlers below. Still probably requires some config changes to the app though that's for sure..

@Seldaek commented on GitHub (Jul 2, 2019): Well I don't know enough about your project to really say, but it sounds to me like you could tell your custom handler to not go further whenever you have your route information. Or to wait/buffer until you have the route info and then tell it to start forwarding log records to the handlers below. Still probably requires some config changes to the app though that's for sure..

kerem commented

2026-03-04 02:15:45 +03:00

Author

Owner

@LaurentMarquet commented on GitHub (Jul 4, 2019):

Thanks again for your time.
It looks too complicated for me, what I was looking for is a kind of method stopPropagation on GetResponseForExceptionEvent because I use a listener on kernel.exception.
As a solution I finally ended in throwing a BadRequestHttpException for the ignored case. If you want to have a look the bundle is at https://github.com/975L/ExceptionCheckerBundle and the exact line is at github.com/975L/ExceptionCheckerBundle@dcbc169c89/Listener/ExceptionListener.php (L169).
It's not really as I want it to be, but it works...

@LaurentMarquet commented on GitHub (Jul 4, 2019): Thanks again for your time. It looks too complicated for me, what I was looking for is a kind of method `stopPropagation` on `GetResponseForExceptionEvent` because I use a listener on `kernel.exception`. As a solution I finally ended in throwing a `BadRequestHttpException` for the ignored case. If you want to have a look the bundle is at https://github.com/975L/ExceptionCheckerBundle and the exact line is at https://github.com/975L/ExceptionCheckerBundle/blob/dcbc169c89e97bb23244fd23fcc69494155e0d08/Listener/ExceptionListener.php#L169. It's not really as I want it to be, but it works...

kerem referenced this issue

2026-03-04 03:06:48 +03:00

[PR #526] [MERGED] Add Hipchat V2 support #1206