wdmnicolas

Hi @bitkurier!

thanks for the report! Your analysis was correct in every detail, and it let us reproduce and fix this
the same day. Fixed in Mail Queue 1.6.2.

Exactly as you described: $wdm_wpma_pre_wp_mail_priority = 99999; is a
top-level assignment, and WP-CLI includes plugin files from function scope,
so it never reached $GLOBALS. The bootstrap add_filter() still registered at
99999 (same scope), but global $wdm_wpma_pre_wp_mail_priority inside a
function read null, so the dispatch bracket called remove_filter(…, null)
and detached nothing. The plugin’s own wp_mail() was intercepted and queued
again while the original row was marked sent – one duplicate per cron tick.

What changed in 1.6.2:

• The priority is now a constant, WDM_WPMA_PRE_WP_MAIL_PRIORITY, as you
  suggested – used at every attach and detach site, so scope can’t come
  between them.
• All of the plugin’s own sends go through a single detach/send/re-attach
  helper (with try/finally), instead of the bracket being duplicated at each
  dispatch site. It detaches at the priority has_filter() reports rather
  than assuming our own, so a re-registered interceptor can’t reach the same
  bug by another route.
• The same latent issue on the plugin version variable is fixed too.

1.6.2 is on WordPress.org now; because of the usual update delay it may take
a few hours to show up on your site. After updating you can remove your MU
plugin – it was a correct workaround and becomes redundant. Any duplicate
rows still in the queue are ordinary entries and can be deleted in the
backend.

Thanks again for the precise write-up, and for the constant suggestion –
that’s exactly the route we took. Reports like yours are what keep Mail
Queue growing; if it earns a spot in your stack, a few words in the review
section help other admins find it.

Best regards!
Nicolas