Subscriptions_queue table containing duplicate entries
| Project: | Subscriptions |
| Version: | 6.x-1.0-beta5 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Hi All,
I am getting duplicate entries in the subscriptions_queue table whenever I comment on any node to which some of the users are subscribed either taxonomy subscription or node subscription. This is sending out duplicate emails.
Also I have noticed that if a user is subscribed to any node which is associated with a taxonomy term "XYZ". And if at the same time he is subscribed to the taxonomy term "XYZ" and upon the updation of the node the subscription_queue will contain two rows one for the node updation and taxonomy updation like this
sqid uid name email module field value
7 11 Vibs abc@yahoo.com node tid 1110
9 11 Vibs abc@yahoo.com node nid 2830
This sends out duplicate emails.
Thanks
Mir Owais
#1
There are two issues here:
1. Taxonomy subscriptions created (exact!) duplicate entries in the {subscriptions_queue} table if a node had multiple revisions. Also, notifications about comments were entered each entry twice. I just fixed this — wait up to 12h for the -dev version to be repackaged.
2. Your example of
is the expected behavior. If you also have a content type subscription, you'll even get a third row. However, Subscriptions filters out the duplicates — I'm seeing only one email being sent.
Are you sure that you're not collecting notifications from more than one email address?
#2
I had also committed a change that eliminated almost-duplicates coming from matching multiple taxonomy terms, but as discussed in #524332-5: DB colum type fixes (make PostgreSQL work), this turned out to be not such a great idea. I have reverted this change.
So, in the end, this lead to the elimination of some redundant {subscriptions_queue} entries, which is a good thing. However, I was unable to reproduce the sending of duplicate emails, and the OP fails to reply, even though he marked this critical, so I'm marking this fixed.
Feel free to reopen if you want to pursue this further...
#3
Automatically closed -- issue fixed for 2 weeks with no activity.