• Sean McGivern's avatar
    Log when SidekiqStatus is used unexpectedly · 2e2f8867
    Sean McGivern authored
    We want to make SidekiqStatus purely opt-in. All known users now set a
    `status_expiration` field on the job, either through the
    `sidekiq_options` on the worker class, or using
    `Worker.with_status.perform_async`.
    
    However, before we start only tracking job statuses for these known
    cases, we want to verify that we are not missing any cases. This commit:
    
    1. Makes the client middleware set a different value in Redis when the
       job has opted in (2 instead of 1).
    2. Changes the status checking method to log when it finds the default
       value (1), indicating that the job was checked but not opted in.
    
    Because item 2 can only work when the job is enqueued or running, it's
    possible we would miss some edge cases that only check job status after
    the job finishes. This should be smoothed out across all runs of the
    various workers, though: if a worker runs so fast that _all_ of its
    status checks show that it is done, then we probably don't need to worry
    too much about checking its status anyway!
    
    This is behind the feature flag log_implicit_sidekiq_status_calls, which
    is disabled by default. It should be safe to use a feature flag here as
    SidekiqStatus isn't read by middleware, only set - it's read by models
    and workers, and the model methods will also be called from HTTP
    endpoints or workers.
    2e2f8867
log_implicit_sidekiq_status_calls.yml 280 Bytes