Mike Perham

Batches break if you use Active Job’s retry_on feature. Since that is quite common, I recommend against using AJ for batches.

Anything is possible but I don’t want to deal with versioning between different Sidekiq gems. Keeping everything all in one gem means that versioning is never a problem.

Given that Rack has no dependencies, I don’t think there’s much to gain. The code in sidekiq/web depends on Rack 3 and the gemspec makes that clear.

If we do that, the natural next step is to run the Sidekiq 6 runtime with the Sidekiq 5 webui. Which is a gigantic hack and will break. And then...

> We also have strict memory limits inside kubernetes, and thus also on the workers. With the usage of FFMPEG to process media, this sometimes causes it to balloon beyond...

Database-based job systems guarantee ACID but at the expense that they scale 10x less than Redis. Eventual consistency is a feature to some; social media generally doesn't need "bank account"...

`ubuntu-latest` is 24.04 on GitHub but 22.04 in `act`, a pretty big issue. Any timeline to fix this default?

There's several concerns. 1. There's no clean, easy way to implement this atomically within Redis. The simplest implementation is with a server middleware but there is a race condition which...

Race condition: - Super fetch puts job in private queue in Redis and starts execution - Job runs thru server middleware - Job is pushed to a quarantine queue -...

I think I should prototype something before promising any specific API. Since retries already support a retry_queue option, we can set that queue to `quarantine_#{job_type}` or similar so that the...