API endpoint to wait for the mail queue to drain?

AI-generated summary

The discussion revolves around whether there is an API endpoint to wait for the mail queue to drain after using the [/admin/email/handle_mail](https://github.com/discourse/discourse/blob/427d54b2b00fa94474c0522eaed750452c4e7f43/app/controllers/admin/email_controller.rb#L145-L159) API endpoint. dachary asks if such an endpoint exists or if it’s possible to get the size of the queue.

dachary was questioned by pfaffman about the problem being solved, to which dachary responded that the problem is clear. pfaffman suggested that the queue is usually processed quickly, but dachary clarified that mail processing is asynchronous and queued, making it necessary to wait for the queue to drain.

Falco stated that there is no exposed API for this purpose, but the Sidekiq Web UI can be used to monitor the default queue. dachary then provided a workaround by using a unique subject/title, searching for the topic, and deleting it once found, which indicates that all preceding emails have been processed.

Bonjour,

After injecting mails using the /admin/email/handle_mail API endpoint, the mails are scheduled for processing. Is there an API endpoint to wait until the queue drained? Or get the size of the queue?

Cheers

What problem are you experiencing that you are trying to solve?

I’m not sure what you’re asking? Is there something ambiguous about the problem expressed above?

You ask for a solution. It’s not clear what the problem is. Mostly those messages are processed pretty quickly and it’s not an issue. I think that if they are queued you might get the list from sidekiq.

Why do you need the list of queued messages? Mostly no queue exists.

You are mistaken: mail processing is asynchronous and queued, reason why it makes sense to wait for the queue to drain.

I don’t think we expose any API for that at the moment. The closest thing we have would be the Sidekiq Web UI for the default queue where this job will wait at /sidekiq/queues/default

Since the processing of emails is sequential, the following workaround works:

  • /admin/email/handle_mail submit a mail with a unique subject/title such as Red Lantern (timestamp) addressed to categoryname@example.com.
  • look for the category id of the category for which the email in setting is categoryname@example.com
  • search with the following parameters:
    • ‘term’ = Red Lantern (timestamp)
    • ‘search_context[type]’ = ‘category’
    • ‘search_context[id]’: category id
  • Loop over ‘topics’ in the result and compare the ‘title’ value to Red Lantern (timestamp)
  • If found it means all mails preceding this one were processed
  • delete the Red Lantern (timestamp) topic using the topic['id'] from the search results