The table core_email_queue_recipients doesn't delete the entries and the message IDs are often the same. Previos customers gets double mails from new orders.
The cron job core/email_queue::cleanQueue is running, but only delete the entries in SQL table core_email_queue.
SQL table core_email_queue_recipients still keep the recipient's e-mail adresses and when new orders arrive, it add new mail addresses with same message_id as previous sent e-mails. Then the new customer and previous (wrong) customer get same e-mail.
When i clean the table manually it works for some days, but then the message IDs starts with "1" and gets double entries. I am wired - since a long time... any Ideas?
Are you truncating the table when you clean it?
hmm, no, i think i just delete all the rows in the table via the "delete" button in phpMyAdmin.
Do i have to use the truncate command? I am not really sure what the difference is.
Thanks for helping here!
I too am having the same issue and am interested in the correct and permanet solution. Did truncate solve the issue?
I am also having this same problem since a recent software upgrade.
Does anyone have a final solution to this problem?
Thanks,
Micah
I solved it with a "dirty" workaround:
i deactivated the cronjob "core_email_queue_clean_up" (via "aoe scheduler") which cleaned up (every 24 h) the Email Queue but did not clean the following email recipient table, which was the problem.
Now the system leaves all entries in both table and now they all have the right IDs and it works perfect since 3 weeks without double recipients !
Hope i could help ya with this lil dirty workaround.
Thanks!
Micah
Hi
I have the same problem regarding mails being sent to wrong customers even if I have upgraded to 1.9.2.1.
I shall probably try your solution. Does it still work for you or have you had any unwanted complications ?
Best regards
Bjørn
I haven't had any issues with truncating the table at all. It seems to be somewhat resolved in the latest release as I haven't cleared it in a while and no dups.
Issue is back. Hosting company is perplexed also. I'll try disabling the cron as suggested above as we simply cannot tolerate this issue.