A customer reported that the Active Job enqueue time doesn't update for retries. So a job that gets retried for the 5th time an hour later, has an enqueue time of 1 hour.
While technically true, the retried job actually had an enqueue time of less than that, it's just that 4 jobs took place during that.
For Delayed Job, which the customer uses, and other libraries we have specific instrumentations for (Sidekiq, Resque, Shoryuken, etc.) we could instead prioritize the library's enqueue time.
This would be a somewhat backwards compatible change, it changes how we track the queue time. Is it what we and customers would expect? It was at least how I expected it to work: the enqueue timestamp is the timestamp of when this iteration of the job is enqueued, not the original one.
Thoughts?
A customer reported that the Active Job enqueue time doesn't update for retries. So a job that gets retried for the 5th time an hour later, has an enqueue time of 1 hour.
While technically true, the retried job actually had an enqueue time of less than that, it's just that 4 jobs took place during that.
For Delayed Job, which the customer uses, and other libraries we have specific instrumentations for (Sidekiq, Resque, Shoryuken, etc.) we could instead prioritize the library's enqueue time.
This would be a somewhat backwards compatible change, it changes how we track the queue time. Is it what we and customers would expect? It was at least how I expected it to work: the enqueue timestamp is the timestamp of when this iteration of the job is enqueued, not the original one.
Thoughts?