-
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