Is there any value in seeing a backtrace for ConcurrencyExceededError?

[reczy]

Hi @bensheldon!

I'm curious if you (or other users) find any value in seeing the full backtrace for concurrency errors? In my case, concurrency errors are expected and common so I don't really view them as "errors" to be further investigated. I am using the following to silence the backtraces:

# config/initializers/good_job.rb

module GoodJob
  module ActiveJobExtensions
    module Concurrency
      class ConcurrencyExceededError < StandardError
        def backtrace
          [] # suppress backtrace
        end
      end
    end
  end
end

Does it make sense to do any of the following?

• hardcode this in GoodJob, or
• include an option to accomplish this in GoodJob via config, or
• include some documentation mentioning that the above code (or something similar) can suppress the backtraces?

[bensheldon]

@reczy Is the backtrace cluttering up the logs?

I think suppressing the backtrace in code is appropriate. I don't think there is a use for the exception other than to trigger the behavior. I'd accept a PR if you wanted to rewrite this to include it:

good_job/lib/good_job/active_job_extensions/concurrency.rb

Line 7 in 2190ed1

ConcurrencyExceededError = Class.new(StandardError)

I also believe it would be better to directly retry the job, rather than raising an exception and catching it. But I haven't done that yet because:

• ActiveJob doesn't expose retry functionality fully; incremental backoff and execution count have to be re-added (it's not too messy, but it's not simple either, and I haven't looked at if the interface changes across Rails versions).
• I know of developers who are using discard_on(GoodJob::ActiveJobExtensions::Concurrency::ConcurrencyExceededError) because of GoodJob's Cron on multiple workers is enqueuing the same job (which is a downside of GoodJob's Cron but I don't want to break that workaround).

But that's beside the clear action step here: suppress the backtrace 👍

[reczy]

Is the backtrace cluttering up the logs?

I think it's a combination of that mixed with the fact that I don't need to know or act on the information provided in the backtrace.

Thanks - PR incoming...