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
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:
topic['id'] from the search results