Page MenuHomePhabricator

After opening a diff, entry on Special:Watchlist sometimes stays unread (bold)
Closed, ResolvedPublicBug

Description

on march 15th (around 18:00 (CET) ) a brief bug was noticed concerning special:watchlist on fr:wikipedia.

Steps to Reproduce:
open a diff of your watchlist, reload the watchlist.

Actual Results:
the article title stay in bold.

Expected Results:
the article title should not be bold anymore.

the bug was "resolved" 25-30 minutes after I first spotted it.

Today (march 17th) around 13:30 (CET) I noticed the bug was strinking again. This time, it lasted around 20 mn.

Hewiki comment:
We already saw it every couple of hours. The API query for unread edits returns all rhe bold ones all the waiting time.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

The unread edits API works well.

Red alert.
Group 1 deployed, and it's much worse now. A lot of edits from previous days suddenly returned to be unbold.

Tagging train deployments if that's made it worse. Posted an alert in #wikimedia-operations

IKhitron added a comment.EditedWed, May 1, 8:11 PM

Digged a little. For each page, that has at least one unread edit, most edits marked as unread, as far as they are on watchlist page, at least. I can see an example page, with 35 from 54 unread today, 36 from 53 yesterday, 12 from 24 the day before yesterday. For example, the last edit 3 minutes ago marked as read, when I did not opened it yet.

Red alert.
Group 1 deployed, and it's much worse now. A lot of edits from previous days suddenly returned to be unbold.

Tagging train deployments if that's made it worse. Posted an alert in #wikimedia-operations

Speaking to reedy in and Thcipriani - It's nothing critical so it's not blocking a train or roll back-able - Advice is to wait until @aaron who was working on it can have a look (see https://wm-bot.wmflabs.org/logs/%23wikimedia-tech/20190501.txt)

IKhitron added a subscriber: Reedy.Wed, May 1, 8:39 PM

A pity that @Reedy believes it's not crucial. It was annoying until today, and now, for a week at least, the Watchlist can't be used at all any more - you can't know what edits are read and what are not. A week without watching pages in all wikis. A rollback of one version will solve the problem. Thank you.

Reedy added a comment.Wed, May 1, 8:41 PM

A pity that @Reedy believes it's not crucial. It was annoying until today, and now, for a week at least, the Watchlist can't be used at all any more - you can't know what edits are read and what are not. A week without watching pages in all wikis. A rollback of one version will solve the problem. Thank you.

If only we have ways of deploying code out of sync of the train...


9:57, 10:09 bold, 9:59, 11:09 unbold.

IKhitron added a comment.EditedThu, May 2, 10:41 AM


Same page, three daily entries (using Watchlist Manager gadget to hide pages with no unread edits).

And I saw a first case of completely read page, marked as unread.

Now I can see that the original issue continues. Listen, the problem is at all in this task, or it's something else?

And now I can see a page with no bold edits at all, but with edits I never read.

Stryn added a subscriber: Stryn.Thu, May 2, 6:36 PM
Izno added a subscriber: Izno.Thu, May 2, 8:51 PM
Dvorapa added a comment.EditedThu, May 2, 10:25 PM

Before sometimes some links stayed bold. Now also some links in my watchlist are unseen, but not bold. Weird is, that the unbold page in my watchlist contains class mw-changeslist-line-not-watched (!). If I change the line to mw-changeslist-line-watched in browser's console, it becomes bold.

JJMC89 added a subscriber: JJMC89.Fri, May 3, 3:33 AM
JJMC89 awarded a token.Fri, May 3, 3:41 AM
aaron added a comment.Fri, May 3, 7:52 PM

After struggling to reproduce anything, I saw T222431 mentioned the old non-default watchlist (that doesn't use JS). I can reproduce some problems when setting that preference on.

IKhitron added a comment.EditedFri, May 3, 7:58 PM

Unfortunately, a lot of people in two wikipedias (at least) are complaining, with js, including myself.

Change 508033 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] Consolidate duplicated unseen change logic and fix inconsistent code

https://gerrit.wikimedia.org/r/508033

DMacks added a subscriber: DMacks.Sat, May 4, 4:37 AM
isaacl added a comment.Sun, May 5, 5:24 PM

@isaacl mentions: "I'm still having the opposite issue that I mentioned before: diffs being marked as read even though they weren't, but on occasion I also see the issue that everyone else is complaining about regarding diffs that have been read"

Maybe I do know why. Does this still happen in safemode?

Yes, looking at my watchlist in safe mode, there are watchlist items that are marked as read but they have not been. Additionally, I clicked on the "View new changes since..." link and a new link appeared that was marked as read.

Well, there is a new bug now, see above. Maybe it comes from this one.

Stryn added a comment.EditedSun, May 5, 6:55 PM

I have seen pages on my watchlist marked as read even though I never read them. I have seen this occurring since 1 May or something. It happens in every wikis. Hopefully this get fixed soon, because many users may lose important messages when they don't know that there is a bug that automatically marks some pages as read.

For me, today it seemed to be the mix of those two underlying issues: I got unbold unread page. I viewed it. It stayed unread as the button for marking it as seen is active

Jonesey95 added a subscriber: Jonesey95.EditedMon, May 6, 12:20 PM

This is a significant problem affecting some of the most active editors, at least at en.WP. If it helps, here are the Watchlist preference settings that I have selected:

Expand watchlist to show all changes, not just the most recent
Use non-JavaScript interface

Hide bot edits
Hide my edits
Hide categorization

Add pages I create and files I upload to my watchlist
Add new files I upload to my watchlist

All other settings are off.

The symptoms that I am seeing are:

  • Some pages say "15 changes" instead of "15 changes | 3 since last visit", as if I have not yet visited the page today.
  • Some pages say "15 changes | 13 since last visit", but if I go to the page history, it shows that there have been only a couple of changes since my last visit.
  • For some pages, when there is a change to the page, the page shows up in bold for all of the days listed on my watchlist, while unchanged pages remain in plain text.
  • There may be other, more subtle symptoms, but those are the two big changes.
Yann added a subscriber: Yann.Mon, May 6, 4:52 PM
4nn1l2 added a subscriber: 4nn1l2.Mon, May 6, 5:02 PM
aaron moved this task from Inbox to Doing on the Performance-Team board.Mon, May 6, 7:52 PM

Change 508033 merged by jenkins-bot:
[mediawiki/core@master] Consolidate duplicated unseen change logic and fix inconsistent code

https://gerrit.wikimedia.org/r/508033

Change 508728 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@wmf/1.34.0-wmf.3] Consolidate duplicated unseen change logic and fix inconsistent code

https://gerrit.wikimedia.org/r/508728

I also started seeing the symptoms described by Jonesey95 about a week ago on enwiki and the read/unread results on my watchlist remain essentially random now.

I have the same problem

We all know that the problem exists; no need for more "me too" comments here. Thanks for your understanding!

Bradv added a subscriber: Bradv.Wed, May 8, 6:39 PM

Well, group 1 deployed. It's much better now, but there are some problems from the last week.

Change 508728 merged by jenkins-bot:
[mediawiki/core@wmf/1.34.0-wmf.3] Consolidate duplicated unseen change logic and fix inconsistent code

https://gerrit.wikimedia.org/r/508728

Mentioned in SAL (#wikimedia-operations) [2019-05-08T23:06:22Z] <krinkle@deploy1001> Synchronized php-1.34.0-wmf.3/includes/specials/SpecialWatchlist.php: T218511 / I42387498dff0b1 (duration: 00m 57s)

Jonesey95 added a comment.EditedThu, May 9, 1:55 PM

Thanks for the patch. Things are much better today, but still not entirely fixed.

On my watchlist, for example, I haven't looked at any pages for about two hours. One page has had 17 changes today, including three in the past two hours. It is marked in my Watchlist as completely read, and is not bold, with the following notation:

(17 changes | history)

It should instead be bold and should say:

(14 changes | 3 since last visit | history)

Most other pages are displayed correctly (for me). I know that makes it frustrating to track down the cause of the problem. I hope that this help you track down the cause. Post here if you need further information.

aaron added a comment.Fri, May 10, 1:26 AM

Thanks for the patch. Things are much better today, but still not entirely fixed.

On my watchlist, for example, I haven't looked at any pages for about two hours. One page has had 17 changes today, including three in the past two hours. It is marked in my Watchlist as completely read, and is not bold, with the following notation:

(17 changes | history)

It should instead be bold and should say:

(14 changes | 3 since last visit | history)

Most other pages are displayed correctly (for me). I know that makes it frustrating to track down the cause of the problem. I hope that this help you track down the cause. Post here if you need further information.

I don't get how the code for the bolding ever worked, at least since 2015, maybe earlier. It was comparing timestamps to booleans and failing to account for new pages with multiple edits. Various classes are also abused/misnamed so that recent changes and watchlists can reuse the same code. I also randomly noticed that WatchedItemStore::getNotificationTimestamp() was using "last-seen time +1s" instead of "first unseen revision time" like updateNotificationTimestamp() does...

Change 509176 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] watchlist: fix nonsensical timestamp/boolean comparisons in EnhancedRecentChanges

https://gerrit.wikimedia.org/r/509176

Krinkle claimed this task.Mon, May 13, 8:28 PM

Change 509176 merged by jenkins-bot:
[mediawiki/core@master] watchlist: fix nonsensical timestamp/boolean comparisons in EnhancedRecentChanges

https://gerrit.wikimedia.org/r/509176

Krinkle reassigned this task from Krinkle to Catrope.Mon, May 13, 10:34 PM
Krinkle triaged this task as High priority.
Krinkle closed this task as Resolved.
Krinkle added a subscriber: Krinkle.

Uhm... definitely not resolved. Am still seeing pages I've visited showing up (bolded) even though I have my Watchlist filtering for "Unseen changes" only.

Reedy added a comment.Tue, May 14, 8:01 AM

Uhm... definitely not resolved. Am still seeing pages I've visited showing up (bolded) even though I have my Watchlist filtering for "Unseen changes" only.

It’s coming in the .5 deployment this week. Should be fixed fully by Friday...

@Joeyconnick: See https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle - resolved in the code base does not mean deployed on the servers :)

Ah... thanks! Newbie lack of understanding of the process. 😳

Group 1 deployed, the problem continues.

aaron added a comment.Thu, May 16, 7:42 AM

Group 1 deployed, the problem continues.

Unread things marked as read?

Group 1 deployed, the problem continues.

Unread things marked as read?

What made to post here was a page in the list I saw, that looked exactly as in F28898796. Meaning some edits bold, else unbold, with no reasonable order.

Stryn added a comment.Fri, May 17, 7:35 PM

Watchlist still show that I have seen some changes even if I haven't. I understood that this was resolved.

If this change has been deployed on en.WP, it did not resolve the problems. Sorry.

JJMC89 reopened this task as Open.Mon, May 20, 6:04 AM

I'm still seeing unvisited pages with changes marked as visited.

Change 511612 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] watchlist: make getLatestNotificationTimestamp() method use the context user

https://gerrit.wikimedia.org/r/511612

Change 511783 had a related patch set uploaded (by Krinkle; owner: Aaron Schulz):
[mediawiki/core@wmf/1.34.0-wmf.6] watchlist: make getLatestNotificationTimestamp() method use the correct user

https://gerrit.wikimedia.org/r/511783

Change 511612 merged by jenkins-bot:
[mediawiki/core@master] watchlist: make getLatestNotificationTimestamp() method use the correct user

https://gerrit.wikimedia.org/r/511612

Change 511794 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@wmf/1.34.0-wmf.5] watchlist: make getLatestNotificationTimestamp() method use the correct user

https://gerrit.wikimedia.org/r/511794

Change 511783 merged by jenkins-bot:
[mediawiki/core@wmf/1.34.0-wmf.6] watchlist: make getLatestNotificationTimestamp() method use the correct user

https://gerrit.wikimedia.org/r/511783

Change 511794 merged by jenkins-bot:
[mediawiki/core@wmf/1.34.0-wmf.5] watchlist: make getLatestNotificationTimestamp() method use the correct user

https://gerrit.wikimedia.org/r/511794

aaron added a comment.Wed, May 22, 7:02 PM

Note that the above patches should be live.

24 hours after group 1 deployment. I do not see any problems.

aaron closed this task as Resolved.Thu, May 23, 9:51 PM

That's not good. For some reason now only the last visited page gets marked as read, then it gets back in bold as soon as I visit another one.

As of 11:15UTC on en-wiki, watchlist seemed to be functioning normally, with one unexpected behavior: When opening a diff, any older unread diffs of that page become marked as read, even though they were not.

Izno added a comment.Fri, May 24, 11:41 AM

As of 11:15UTC on en-wiki, watchlist seemed to be functioning normally, with one unexpected behavior: When opening a diff, any older unread diffs of that page become marked as read, even though they were not.

That's how it functioned previously.

As of 11:15UTC on en-wiki, watchlist seemed to be functioning normally, with one unexpected behavior: When opening a diff, any older unread diffs of that page become marked as read, even though they were not.

That's how it functioned previously.

Yes, this is a standard behavior, even if it does not seem to be correct. Partially it can be solved by T171717: Allow seeing the diff of all changes since last visit directly from Special:Watchlist