-
-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Monolog handler #808
Add Monolog handler #808
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I think it makes sense that the passed hub is used for logging instead of always getting the currentHub
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job, LGTM! 👍 The handler is very clean and slim!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 💪
We're missing just one small thing! The changelog! |
9192e0d
to
e8f5aa9
Compare
Done, I always forget to update it! |
Amazing! Thank you 👍 |
Trying to update but am being blocked by this PR not being released. What's the ETA? 😄 |
No ETA, but this will be released with 2.1. Check out the milestone for progress: https://github.com/getsentry/sentry-php/milestone/2 |
Alright, thanks for the reply! I'll check back in a while and stay at sentry/sentry-symfony 2.x for now as it seems to not cause issues with Symfony 4.x |
This PR implements a Monolog handler and closes #790, which is a highly requested feature. Code is a stripped down version of the one submitted by @HazAT in the official Monolog repository. There are a few questions to discuss before merging:
Hub::setCurrent()
method is called) it's not clear how this should affect the handler itself: e.g. if the handler is binded to an old or different hub than the current one it will report errors to the wrong client (if it's different between hubs)captureMessage
method provides no way to pass the exception while calling thecaptureException
has no way to pass the message. To solve the issue, instead of calling those methods like in the original PR, I'm building the raw payload of data to build the event from and I'm using thecaptureEvent
method directly. Since the two methods mentioned before have a slightly different behavior regarding the stacktrace capture (attach_stacktrace
option), the same exact behavior cannot be accomplished with such way