Skip to content

G
gitlab-ce
Switch branch/tag
  1. 30 Nov, 2021 1 commit
    • 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
  3. 25 Nov, 2021 39 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7