Set consistent context in delayed_job integration

[mike-stewart]

Goal

Currently, a context is only set on DelayedJob errors if a display_name is set on the job, which is not always the case. The default context that it falls back to (top stack trace line) doesn't seem useful.

The default results in errors like ActiveRecord::StatementInvalid app/models/foo.rb:100. It does not indicate which job is failing, so one cannot understand the problem at glance in the dashboard.

Other integrations attempt to set a useful default context, see:

bugsnag-ruby/lib/bugsnag/integrations/resque.rb

Line 46 in 56f387e

report.meta_data.merge!({:context => "#{payload['class']}@#{queue}", :payload => payload})

bugsnag-ruby/lib/bugsnag/middleware/rails3_request.rb

Line 19 in 56f387e

report.context = "#{params[:controller]}##{params[:action]}"

I think it would make sense to use the job name as the default context. This is consistent with other error monitoring tools I've used.

Changeset

Tests

Tests pass without changes. Let me know if you think additional coverage is needed.

Discussion

Alternative Approaches

I first tried defining a before_notify_callback to override the context, but that did not work.

Outstanding Questions

Linked issues

Review

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • Initial review of the intended approach, not yet feature complete
  • Structural review of the classes, functions, and properties modified
  • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• Consistency across platforms for structures or concepts added or modified
• Consistency between the changeset and the goal stated above
• Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• Usage friction - is the proposed change in usage cumbersome or complicated?
• Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• Concurrency concerns - if components are accessed asynchronously, what issues will arise
• Thoroughness of added tests and any missing edge cases
• Idiomatic use of the language

@snmaynard @Cawllec

[Cawllec]

This LGTM, though I'm going to confirm changing the potential context won't cause any issues first.

[Cawllec]

Hi @mike-stewart, I'm going to take it on from here to add some more end-to-end tests. Thanks for the contribution!

[mike-stewart]

@Cawllec Any ETA on this one?

[snmaynard]

We have some longer term work going on adding breadcrumbs to the ruby notifier and we will slot this in after that. Might take a few weeks. You can always pin to your fork until we have got to merging this down if you need it sooner.

[mike-stewart]

Any plans to pull this @Cawllec @snmaynard @phillipsam?

[abigailbramble]

Hi @mike-stewart we are still planning to pull this when priorities allow.

[imjoehaines]

Thanks for the PR @mike-stewart! I've fixed the conflict and added an end-to-end test in #615

[abigailbramble]

A fix for this has now been released in v6.16.0.