"email digest sender command" and locked>0

All,

Have tried various recommended means to address a constantly recurring log item:

info: {“message”:“Email digest sender command”,“sent”:0,“failed”:0,“pending”:0,“locked”:4}

This was discovered when clicking “save” (via web browser accessing passbolt in it’s own browser tab) and it was taking an abnormally long time to actually save the entry and return to the list of password entries.

Here are some of the things that were tried (amongst others):

sudo su -s /bin/bash -c "/usr/share/php/passbolt/bin/cake sender" www-data

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake passbolt send_test_email --recipient=<recipient_emailaddress>"

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake cache clear_all"

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake passbolt show_queued_emails"

All of the outputs, tests and actions work as expected. Have even checked the email queue table in mysql and there are no errors listed. At this point, at a loss as to where the “locked:4” is coming from. The error messages are occurring every time an item is opened and saved in the GUI (via web browser). Appears to be linked to the ‘save’ action of an object. The test emails (via CLI and GUI) work.

Anyone have any ideas as to where else one should look and/or how to address? Perhaps worth note: when clicking “save” it’s taking an abnormally long period of time before it actually ‘saves’ the updated entry.

Out of curiosity, tested with the app on IOS - the ‘save’ is almost instantaneous and doesn’t result in the above error.

Fine with purging any sort of email “queue” to get past this issue - it that is the simplest path forward.

Thanks!

Edit/Update: found the four items in the email_queue that had a “locked” value set. These were old (almost two years old). As they’re “far gone”, setting to zero removes the “locked” appearance (can put the “locked” flag back if appropriate). However, doesn’t change anything about the long delay when trying to save via browser. Those log messages might be a red herring? Did try modifying an entry via IOS app, then modifying that same entry via web browser - update was fast via IOS app and long delay via web browser. Then went back re-modified entry via IOS app - save was fast. While not timing, it appears to be a couple seconds on IOS app vs. 30+ seconds via web browser - to provide sense of differential.

Hello @doubts,

It’s safe to purge the email queue (e.g. truncate email queue table for example), if you want to rule out if it’s this table making the creation slow.

However by the description, fast creation of resources on iOS but not in the browser extension, it looks like it could be something else. If you can inspect the behavior of the browser extension and try to find out which step is slow (is it slow when the request is being sent to the server, is it when the resource is being encrypted, etc.) we can try to narrow it down.

Cheers,