Closed (fixed)
Project:
Message Subscribe
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 May 2014 at 09:19 UTC
Updated:
22 Mar 2017 at 17:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
capuleto commentedComment #2
amitaibuThanks, Setting correct status.
Can you add a simpletest to this as-well?
Comment #3
capuleto commentedThanks for the feedback.
I've just added a test for the issue.
Comment #4
roysegall commentedDon't pass to 80 line characters.
No need for the issue URL.
user1 => User 1
Forgot a dot(.) in the end.
Comment #5
capuleto commentedApplied suggested changes.
Comment #6
capuleto commentedComment #7
capuleto commentedComment #8
capuleto commented@RoySegall.. Is it the last patch ok?
Comment #9
roysegall commented@capuleto I'll try to have a look on this tomorrow and run the simple test on my local computer due to the infinity queued of the simpletest(#2255301: Simple test are queued for ever.)
Comment #10
roysegall commentedI don't see any use of the last UID in the simple test when passing the options to the message_subscribe_send_message.
Comment #11
roysegall commentedComment #12
capuleto commented@RoySegall You could run the tests without applying the patch to "message_subscribe_send_message".. and you will see that " testProvidedUserIdsAreSplitAccordingToRangeValue" fires more than the 3 expected e-mails as the issue is the internal use of "last uid" when the list of user ids are provided along with range.
Comment #13
capuleto commented@RoySegall I've updated the test to include "last uid" to subscribe_options array.
Comment #14
rjacobs commentedWould someone be able to provide a bit more context for this issue? What are the related symptoms? What I can gather (via a scan of the code) is that this bug leads to an incorrect uid being associated with the first message of a batch/range whenever that range of uids to process in exceeded within message_subscribe_send_message()? Does this mean that this bug is only an issue when the queue is used (i.e. message_subscribe_use_queue = TRUE)?
We have uncovered a case where some subscribers seem to get the incorrect mid associated with some of their notifications, and I'm trying to see if it may be linked to this issue. For example, we may have a user subscribed to 5 entities, and an event takes place that simultaneously triggers a message associated with all 5 of those entities. In this case the 5 messages will be generated correctly (each with a distinct mid and related field data) and the user will receive 5 notifications (as expected). The problem is that the 5 notifications received are not distinct, and several appear in duplicate (e.g. we would expect 5 notifications each associated with one of the 5 messages, but instead we see 2 dup notifications associated with message 1, and 3 dup notifications associated with message 5). In our instance message_subscribe_use_queue is set to FALSE.
So this is clearly representative of some kind of mismatch between mid and uid data processed in message_subscribe_send_message(), and passed to message_notify_send_message(), but it's really hard to tell if it could be tied to this issue or something else entirely.
Comment #15
amitaibuIs this relared? #2299083: Users receive duplicate notifications when queue is enabled
Comment #16
capuleto commentedHi @Amitaibu and @rjacobs.
This issue is covered by the attached test
We found out that if we provide the uids and range in the subscribe_options array, the queue job didn't respect the "last uid" stored internally.
Meaning that the subsequent job queues will start from the very fist element of the "uids" array if the current job did not manage to send to all provided users.
In our case it was sending the same email several times to the same user, but every message sent was triggered by a different job queue.
Comment #22
capuleto commented@Amitaibu and @RoySegall.. the testbot seems to be able to run the tests..
I've re-queued the latest one..
Comment #23
amitaibu@capuleto, is this related #2299083: Users receive duplicate notifications when queue is enabled?
Comment #24
amitaibubtw, Feel free to open a PR in the GitHub repo instead of here
#2362663: Move issue queue to Github
Comment #26
capuleto commentedOnly tests patch.
Comment #28
capuleto commentedPatch and tests.
Comment #29
capuleto commentedTrigger tests.
Comment #30
oturpin commentedHi All,
Got a question on this patch: Would it be possible that the $index equals the last member of the uids array ? (ie the former loop over the uids reached the last member of array having just "range" members)
In that case, the queue would be re-initialized with the full list of uids from the message_subscribe_get_subscribers ?
Thx for feedback
Comment #31
amitaibuMerged, thanks.
Comment #33
amitaibuComment #35
jelo commentedI realize that this issue is closed, but for anyone looking for solutions to the duplicate message issue it may be helpful to know that this patch does not seem to fix the problem. amitaibu asked several times if this issue is related to #2299083. Even with this patch implemented I am still experiencing the problem that a number of users receive multiple duplicate notifications when queue is enabled... Just had a case where the notification was sent 7 times within 15 minutes. So, the two issues seem to be distinct.