Ben Sheldon [he/him]

@francois-ferrandis great question! Yes, it is dangerous to use `Timeout.timeout` in GoodJob. That's because GoodJob, like Puma, is multithreaded and `Thread.raise/kill` can leave shared resources (like Active Record database connection...

Thanks for reporting! What is the error class that gets raised with that message? I can add that to the retryable list that will give it 30 seconds to succeed...

This exception is already part of GoodJob's LISTEN/NOTIFY reconnect list: https://github.com/bensheldon/good_job/blob/90ea269a27c21f0425cce229c8d2519e9e2a6ff2/lib/good_job/notifier.rb#L25-L36 GoodJob will always attempt to reconnect perpetually on any exception, the only difference here is that these specific reconnect...

💖 Thank you @sasharevzin for that link! I think that's right; the feature to use is Concurrency Controls: https://github.com/bensheldon/good_job#concurrency-controls And sorry @gagalago for overlooking this when you originally posted 😞

oh! I understand now about the desire for multiple keys. The challenge with multiple keys is that the _key_ requires its own indexed column in the database because it's used...

I think so 👍🏻

Oh no! That's bad! 😞 I don't have an answer for you right now. I think "We could ignore the problem until rails 7.1.0 is released." is the reluctant path...

> Is it possible to add something like that here as well? Yep, definitely. > Since goodjob is thread based as well - would you say we will benefit from...

That looks like a good example for me 👍🏻 Would you make a PR and put this in a `examples/systemd` directory? Thank you!

Please make a PR! 🙌 We're all winging it.