Evan Huus

In the neighbourhood (though this is very much less important and somewhat distinct) it would be nice if death handlers could know whether the job is going to the morgue...

The inconsistency means that, whatever way you decide to unify this behaviour, it would have to be a breaking change in a major version. In the meantime (since 8.0 was...

> I'm not sure this should be considered a breaking change. Is invoking death handlers a compatibility issue? I can imagine cases where a user might have come to rely...

The proposed diff looks correct to me but incomplete. There is also a case in `def process_retry` (currently line 189) that needs changing. That refactor will be a touch more...

Thank you! --- While reading the new code, I noticed a small pre-existing oddity, that if `sidekiq_retry_in` and `sidekiq_retries_exhausted` are both configured, then their interaction is inconsistent (because `sidekiq_retry_in` only...

Going on a bit of a tangent, but keeping https://github.com/sidekiq/sidekiq/wiki/Error-Handling#no-more-bike-shedding in mind... There are a lot of practical cases (e.g. any kind of third-party API call timing out in a...

Oh whoops, my bad looks like the version of the ES gem we're on is super-old, this was changed in v8 https://github.com/elastic/elasticsearch-ruby/blob/main/CHANGELOG.md#800. Would be nice if that `.body` was made...

Hum, yeah. What about making the args hash "strict" (is that a thing that ruby lets you do?) so that accessing a missing key at least raises instead of producing...