Sidekiq is the incumbent in Ruby, and Ruby is the language the remote SDK tier makes cheap to
support (#834).
The guide is straightforward if the client exists and pointless if it does not, so this is
explicitly blocked on #834 and should stay closed-as-blocked until then.
When it is unblocked:
perform_async / perform_in / perform_at → enqueue, delayed enqueuesidekiq_options — queue, retry, backtrace, dead — → the options surface- the Sidekiq Web UI → the FlexiQ dashboard
- the retry set and the dead set → retries and the dead-letter queue, which is inspectable and
replayable
- unique jobs (the enterprise feature, or
sidekiq-unique-jobs) → unique_key and idempotency,
which are in the core rather than a plugin
The honest delta matters more here than in the other guides. A Ruby client is producer-side
only: it enqueues, it does not execute. A Sidekiq user replacing Sidekiq needs workers, and
until the executor door has a Ruby implementation the answer is that the workers run in another
language. Say that at the top of the page, not at the bottom.
Sidekiq is the incumbent in Ruby, and Ruby is the language the remote SDK tier makes cheap to
support (#834).
The guide is straightforward if the client exists and pointless if it does not, so this is
explicitly blocked on #834 and should stay closed-as-blocked until then.
When it is unblocked:
perform_async/perform_in/perform_at→ enqueue, delayed enqueuesidekiq_options— queue, retry, backtrace, dead — → the options surfacereplayable
sidekiq-unique-jobs) →unique_keyand idempotency,which are in the core rather than a plugin
The honest delta matters more here than in the other guides. A Ruby client is producer-side
only: it enqueues, it does not execute. A Sidekiq user replacing Sidekiq needs workers, and
until the executor door has a Ruby implementation the answer is that the workers run in another
language. Say that at the top of the page, not at the bottom.