Rosa Gutierrez

> Do you have any documentation regarding how the web processes engage and release the db connections? We have puma worker/threads Active Record is the one checking out and releasing...

> I made an incorrect assumption that Solidqueue was somehow tied to our Rails apps Puma configuration, but given the fact that it boots up from the SolidQueue::Cli.start command, I...

> Worker: 5 dynos, with SolidQueue processes set to 1 and threads unset, which has a default of 3. So for each dyno, it spins up 3 polling workers in...

> a SolidQueue worker, a Puma thread, a SolidQueue thread, and a "dyno" worker is making this even trickier to try and talk through. I meant that each thread was...

Could you please read everything I wrote above but more carefully? In particular the part about the different processes Solid Queue runs: supervisor, workers, dispatcher. The quoted phrase refers to...

Looks like the workers processing these jobs are crashing or being killed somehow. Can you access logs in that instance to see what it might be?

> Locally, it seems that the recurring job is getting enqueued but never executing. Do you have local logs for what your Solid Queue worker is doing?

`config.solid_queue.silence_polling` option is set to `true` by default, so you shouldn't see the polling queries (which are usually the most noisy). Then you can also set a separate logger for...

Or if you want to mute the Solid Queue logs completely, you can set: ```ruby config.solid_queue.logger = ActiveSupport::Logger.new(nil) ```

> However, it's still odd that the job would throw a `SolidQueue::Processes::ProcessExitError` instead of being marked as completed. Yes, that's what would happen. `SolidQueue::Processes::ProcessExitError` is not thrown by the job....