This is a split off of T139147: Mark notifications as read/unread with blue dot does not work in some circumstances to specifically deal with this bug, which seems to be repeating itself, as reported by @IKhitron
To my understanding, the issue is that an unread notification is marked 'read', and then, a few hours later, may reappear as if it is unread again, without explicit action by the user (@IKhitron please correct this if I got it wrong)
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Mark all notifications in a foreign bundle as read | mediawiki/extensions/Echo | master | +5 -1 |
@IKhitron I'm going to try and see if we can pinpoint exactly what happens here, because this is worrying, especially since we can't seem to properly reproduce something you clearly see often. If you don't mind, a few questions to clarify the issue:
Any information about where, when, and how this happens will be extremely useful, seeing as we can't manage to consistently reproduce this (or at all right now)
Hi, Moriel, how are you? We did not talk a lot of time.
Thank you for this task.
About your questions:
I don't think so. It just happens.
Thanks again.
Hey :)
Thank you for this task.
About your questions:
- Sometimes alerts only, sometimes notices only, sometimes both.
- I can't remember any cross wiki revert. I'll pay attention. About bondle - it happens with and without.
- Not always.
I don't think so. It just happens.
Thanks again.
Unfortunately, this doesn't give me enough information to fix this problem, especially since we can't seem to be able to reproduce it.
When you see this again, it would really help if you can see if there is any sort of connecting elements to those read/unread jumps. It might be a certain wiki, or maybe certain types, bundles, cross-wiki, etc. Please report back if you find anything like this, so we can try and figure out what the problem is and fix it.
On a separate note, we've upgraded and updated a bunch of the features, and those should be in production soon - that might fix the issue too, in case this is some fluke of the code.
I agree, of course.
On the other hand, reproductiin isn't the only way. Tracing seems me much better in this case.
Unfortunately, @IKhitron , there's no way for me to trace these things without either reproducing the problem or having more details about notification types or some more information about the bug.
I'm changing the status of this bug as "stalled". If and when this happens again, please try to see if there's information you can get that is related to the bug - types, bundles, hours of the day, wiki, cross-wiki, or any other elements that can help me and the team figure out what is going on.
Unfortunately, there's no SQL query I can run that will show me what the problem is. The only query that I could do will fetch notifications with their 'read' status either on or off. This will tell me whether the notification is read or unread -- it will not tell me whether it used to be read and then reverted or vise versa.
There is nothing I can do remotely in this case. I have to get more information about this bug - or more iterations of it from more clients and circumstances - to be able to pinpoint (or at least generally know what to check for) in order to see what the problem is, and then provide a solution.
You did not understand me, @Mooeypoo. I'm not talking about SQL query, I am talking about SQL tracing. You have a lot of tables, create one more, call it Tmp1. Every time somebody observes his unread notifications, add their ids to the table, with user data. Every time notification become read, add its id to the table as different boolean event, in vs out. Add this code in the next deployment and remove it in one after. You'll get a full statisics for a whole week to analyse. It will take an encredible large space, but it's nothing against the revision table. Seems very easy to me. Btw, it happens again and again.
Change 302817 had a related patch set uploaded (by Sbisson):
Mark all notifications in a foreign bundle as read
Change 302817 merged by jenkins-bot:
Mark all notifications in a foreign bundle as read
This was definitely a possible cause. I'll move this to QA so it can be closed.
Please re-open if it happens again after this is deploy (2016-08-09).