Yes, I’ve seen this problem before with WP_Async_Request and HTTP Auth.
I recommend that you filter ‘http_request_args’ and add an Authorization: Basic header to the $args['headers'] array. See https://developer.ww.wp.xz.cn/apis/making-http-requests/authentication/
Many thanks, just giving this a go. BTW if I want to purge (as in delete) the queued items that have piled up while this issue has been active, do I just manually delete all entries in the bpges_queued_items table?
Yes, you can simply delete items from that table.
Looking at the live site, it has over 15,000 queued items dating back to a year ago. But AFAIK notifications are going out. I know it’s a slight tangent but this strikes me as odd if deleting them is how to ‘de-queue’ them (there being no flag for each record to keep it and mark it as sent).
The async process should delete the items after they’ve been included in an email. https://github.com/boonebgorges/buddypress-group-email-subscription/blob/master/classes/class-bpges-async-request-send-queue.php#L120 Are the remaining items all ‘immediate’, or all ‘dig’/’sum’, or a mix of both?
There’s a bunch of dig/sum that are today, presumably about to be sent. Anything older is immediate.
Hm. I guess I’d suggest monitoring going forward, to see if immediate items continue to pile up once you have the HTTP Auth issue figured out. If so, I can try to help debug why the items aren’t being cleared – either they’re not actually going out, or they’re going out but not being deleted from the table.
Thanks. To be clear, there’s a ‘pile-up’ of items in the DB queue on both the staging and production environments.
Most of the old ones on staging will be copied from production as we periodically copy production data to staging. Staging is where we have HTTP Auth, so it’s also expected that nothing will have been sent out – so on top of old ‘immediate’ items copied from production, there are also a number of ‘dig/sum’ items piling up from failed sends on staging (queue processing blocked by HTTP Auth).
However, there’s no HTTP Auth on production, so that’s possibly another issue. The client hasn’t reported missing notifications, so it seems likely that they’re being sent but not cleared from the queue. However, I’ll need to confirm that through monitoring.
FYI the HTTP Auth fix works for staging – email notifications are now being sent from there.
I’ve looked closely at one of the notifications on production which is still in the queue table. It’s from 3/2/23. The WP Mail SMTP log shows it as ‘Not sent’, and indeed it doesn’t show in the DotDigital email long. There’s nothing in the on-site WP Mail log to give further clues as to why it’s not sent. Also, there are many successful sends in the same batch, and successful sends from other batches on the same day going from the same address and to the same address (just notifications for updates in different groups).
Anyway, I’ll close this issue as solved, many thanks. Will get back to you if I manage to get more details on the other issue.
