Redmine

Mails are always processed asynchronously.

By default, we use a very simply queue implementation (ActiveJob::QueueSdapters::AsyncAdapter which processes background jobs in a separate thread of your application server process. This however is prone to lost jobs as the scheduled background jobs (such as sending notification mails) are not stored in the database. If the job is not successful or the application server process dies for any reason, the currently running and any further scheduled jobs are lost.

The advantage of this default queue (and the reason why we use it by default) is that is does not require to maintain a separate process (and Redis database) to process the background jobs. This can reduce the environment requirements of Redmine. For a production environment, it is still likely a better idea to move to a durable queueing implementation

Because of that, we recommend to setup a separate durable queue. We generally support all implementations which are supported by ActiveJob. This includes

• Sidekiq (which stores scheduled jobs in a Redis database)
• Resque (likewise)
• DelayedJob (which can store jobs in your Redmine database)
• likely also solid_queue (which can also stores jobs in the Redmine database). I have not personally tested this though.
• and others

Thank you for your reply.

If the job is not successful or the application server process dies for any reason, the currently running and any further scheduled jobs are lost.

I see. I had overlooked this perspective.
This time, I have introduced Sidekiq.

When Redmine starts using Rails 8.x, can we expect solid_queue https://guides.rubyonrails.org/active_job_basics.html#production to be adopted as the default?

Kind regards,