Maintain correlation_id across Sidekiq retries
Previously this code was overriding the correlation_id in the job
hash. That's because retries were generating a new context and this new
context had a new random correlation_id
.
Now we take the previous correlation_id
into account when generating a
new context.
How to test
- Add a
raise 'foobar'
to any worker - Watch the logs in
gdk tail rails-background-jobs
- Call a
perform_async
from the rails console for that sidekiq worker - Wait a minute for it to retry
- See whether the
correlation_id
matches for the retry jobs and the original job
Without this patch you should see that they are different. With this patch they should match. I have tested this locally.
Edited by Dylan Griffith