[jorge-d]

Well Sidekiq is free to use. It's only the pro version that he charges and the free version code is open source.

I don't see the problem in having that kind of business model, it still allows the community to thrive and offers entreprises a way to have premium support.

Plus it allows him to invest more time in maintaining the free version.

[phamilton]

I have no problem paying for the Pro version, but one if its marketing pitches is "enhanced reliability", which is a wild marketing spin on "the free version will lose jobs in fairly common scenarios".

In sidekiq without super_fetch (a paid feature), any jobs in progress when a worker crashes are lost forever. If a worker merely encounters an exception the job will be put back on the queue and retried but a crash means the job is lost.

Again, no problem paying for Pro, but I would prefer a little more transparency on how big a gap that is.

[arkasan]

I wish this was prominently documented. Most people new to Sidekiq have no idea that the job will be lost forever if you simply hard kill the worker. I have seen a couple of instances where the team had Sidekiq Pro, but they had not enabled reliable fetch because they were unaware of this problem

[mperham]

The free version acts exactly like Resque, the previous market leader in Ruby background jobs. If it was good enough reliability for GitHub and Shopify to use for years, it was good enough for Sidekiq OSS too.

Here's Resque literally using `lpop` which is destructive and will lose jobs.

https://github.com/resque/resque/blob/7623b8dfbdd0a07eb04b19...

[aqme28]

When we used Sidekiq in production, not only did I never see crashes that lost us jobs, but there are also ways to protect yourself from that. I highly recommend writing your jobs to be idempotent.

[durkie]

how often do your workers crash? i rely heavily on sidekiq and don't think I see this very often, if ever.

[tebbers]

Exactly why we refuse to use Sidekiq. “Hey, you have to pay to guarantee your jobs won’t just vanish”.

No thanks.