-
-
Notifications
You must be signed in to change notification settings - Fork 730
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 simpler Alert.raise interface to notify Bugsnag #12992
Conversation
This reverts commit 2eec3d6. We started tracking 404 errors out of interest without an actual problem to solve. Now we face rate-limiting in our Bugsnag account. And we didn't use these 404 reports in the two years this code was active. We don't even act on all 500 errors. So while our resources are so constrained, let's keep our focus on the severe errors and user reports and ignore the rest. 404 errors are mostly generated by vulnerability scanners.
Needs human to review Bugsnag account.
Bugsnag expects a string as value, not an ActiveRecord object. The result was just "filtered" data, not showing any of the order's attributes. Since wanting to share the order data seems a common pattern, I added a convenience method for it.
I still think that some of these objects won't be visible in Bugsnag but I don't want to test any more on cases that were broken before and may not be relevant now.
Somehow Bugsnag doesn't report in CI environment and I have no idea how to circumvent that. And I don't want to spend more time on this.
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 work, looks like it will ensure more consistent error reporting, and great cleanup along the way.
# You need to have a valid Bugsnag API key to record this test. | ||
# And after recording, you need to check the Bugsnag account for the right | ||
# data. |
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.
Thanks for adding instructions!
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.
Thanks for that, that was overdue :)
I think you missed one of the call with an order object.
app/jobs/subscription_confirm_job.rb
Outdated
Alert.raise(e) do |payload| | ||
payload.add_metadata :order, :order, order | ||
end |
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.
This should be :
Alert.raise(e) do |payload| | |
payload.add_metadata :order, :order, order | |
end | |
Alert.raise_with_record(e, order) |
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.
Thank you. Applied.
What? Why?
Bugsnag's API is great for general purpose but overly complex for our use. It also changes over time and we often make mistakes using it. So this class aims at:
In a previous PR, we tried to fix the syntax like this:
But that didn't work. I think that the
order
object was converted to a hash before but newer versions of Bugsnag have less magic. And passing the order as value doesn't work either, it just got filtered out when I tested. So this pull request adds some logic to convert an ActiveRecord object to proper Bugsnag metadata. We may want to expand the functionality in the future but I didn't want to spend too much time on this now.Hopefully this PR is enough to propagate correct use from now on.
What should we test?
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
Documentation updates