Resume Queue Processing does not work

Issues
1

Issue Description

I paused queue processing to free up some CPU to do some work on the server.

After I had done, I resumed queue processing and noticed CPU usage still sitting on 0% after a couple minutes, I checked the email queue and it was still sitting on the same number of emails, not decreasing.

I sent an email to check submittions still worked, and then the queue started processing again.

Expected Behavior

Message queue to start processing immediately after the resume button is pressed.

Actual Behavior

Message queue does not resume processing untill another email submission comes in.

Reproduction Steps

  1. Send some emails (a few thousand)
  2. Click the pause queue procession buttin while the server is processing emails
  3. Observe queue processing has paused, both CPU go idle and message queue doesnt decrease (expected)
  4. Click resume processing queue
  5. Observe CPU remains idle and message queue does not decrease (unexpected)
  6. Send a submission
  7. Observe procession queue now resumes.

Stalwart Version

v0.16.x

Installation Method

Binary (Windows)

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This does look like a genuine bug in the current queue manager code. When you pause the queue, the manager sets next_refresh to 24 hours in the future and stops processing (QueueEvent::Paused(true)). When you unpause (QueueEvent::Paused(false)), the handler only flips is_paused back to false but returns false for refresh_queue, and it does not reset next_refresh. Since the main loop only recomputes the delivery schedule when refresh_queue is true or the (still-24h-away) next_refresh timer fires, the queue effectively stays idle until some other event (like a new message submission) forces a refresh, exactly as you observed.

So the workaround you found (sending a new message to “kick” the queue) is consistent with this code path, and it’s not something you’re doing wrong. This looks like a bug worth flagging to staff for a fix in the resume handler so it forces an immediate queue refresh.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.13 which will be released this week.