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:
Abstracting from Bugsnag, open for other services.
Simpler interface to reduce user error.
Central place to update Bugsnag API usage when it changes.
In a previous PR, we tried to fix the syntax like this:
- payload.add_metadata :order, order
+ payload.add_metadata :order, :order, order
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?
I'm not sure if we can test this properly.
We would need to know about an existing bug that triggers Bugsnag and try to do that again on staging.
Then you can compare the data there.
This code affects only code paths that are not expected to happen on a regular basis.
Release notes
Changelog Category (reviewers may add a label for the release notes):
[ ] User facing changes
[ ] API changes (V0, V1, DFC or Webhook)
[x] Technical changes only
[ ] Feature toggled
The title of the pull request will be included in the release notes.
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
orderobject 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