Mike Perham

Rails' Executor wraps the job processing. I'm not sure how that meshes with a DB transaction and I'm still unclear what this change might look like.

One line in the sand I’ve drawn is that Sidekiq doesn’t touch any DB. On top of that no one has shown me non-transactional jobs to be an actual problem...

I've been working on a refactored Sidekiq::Client today which has a serialize API. The issue I'm struggling with is due to the `enqueued_at` element. I assume your `serialize` caller expects...

I'm kinda stuck here. I don't see a clear way forward which does not significantly increase the complexity of the Client impl but there's little interest or call for this...

> Job.new(*args, **opts).serialize => Hash This will never happen. The contract is `Job.new.perform(*args)`. I understand why serialization might be useful for some. I have yet to see an implementation of...

I'm at Railsconf this week so I'll snooze this until next week.

I don't see a way forward here yet. Providing this API while preserving 100% backwards compatibility seems difficult at best. Have you considered providing your own alternative Sidekiq client? The...

Isaac, I would suggest a blog post discussing your system along with a link to it in the wiki. You are right that it doesn’t feel appropriate to put that...

🤩 Holy cow. Maybe we could have checkboxes in the table rows which show/hide each job type within the graph? And have the graph only show the top 5 by...

That's a reasonable question. We could either add more smarts to the deploy mark by supporting an explicit `scm_label` which could be a git sha, git tag, svn id, etc....