Page MenuHomePhabricator

After opening a diff, entry on Special:Watchlist sometimes stays unread (bold)
Open, HighPublicBUG REPORT

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
aaron moved this task from Inbox to Doing on the Performance-Team board.May 6 2019, 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.May 8 2019, 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.EditedMay 9 2019, 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.May 10 2019, 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.May 13 2019, 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 closed this task as Resolved.May 13 2019, 10:34 PM
Krinkle reassigned this task from Krinkle to Catrope.
Krinkle triaged this task as High priority.
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.May 14 2019, 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.May 16 2019, 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.May 17 2019, 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.May 20 2019, 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.May 22 2019, 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.May 23 2019, 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.May 24 2019, 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

IKhitron reopened this task as Open.May 27 2019, 4:02 PM

Pay attention. The wrong data in watchlist problem is resolved, but the original issue of this task, "After opening a diff, entry on Special:Watchlist sometimes stays unread (bold)", isn't.

Izno added a comment.May 27 2019, 5:58 PM

Pay attention. The wrong data in watchlist problem is resolved, but the original issue of this task, "After opening a diff, entry on Special:Watchlist sometimes stays unread (bold)", isn't.

You should probably provide new instructions to reproduce. I've not had this issue all day today.

You should probably provide new instructions to reproduce. I've not had this issue all day today.

Same as in the task description.

Izno added a comment.May 27 2019, 6:05 PM

You should probably provide new instructions to reproduce. I've not had this issue all day today.

Same as in the task description.

Yup, cannot reproduce. You may need to clear cookies, etc.

It was not reproducible from the beginning, just suddenly happening a couple of times every day. But no problem, I'll do this.

Once again, after I fulfilled your recommendation.

I can confirm, it is much better than before, but still sometimes leaves visited change marked in bold

Dvorapa added a comment.EditedJun 10 2019, 9:53 PM

Sometimes I visit a new watchlist entry, the entry becomes seen, but some - already visited - change underneath gets marked as unseen. I click to that change and it is marked as seen, but the first entry is marked as unseen back.

  • Open watchlist

  • Open the bold page
  • Open watchlist again

  • Open the bold page again
  • Open watchlist once more

Note: Some users on Czech Wikipedia complained today too.

Lofhi added a subscriber: Lofhi.Jun 12 2019, 6:11 PM
Jeff_G added a comment.EditedJun 18 2019, 11:14 PM

It is still happening for me today. In the attached screenshot, I am "User:Jeff G." and my edit of 18:41 (UTC-4, EDT, 22:41 UTC with screenshot taken around 23:00 UTC) should have marked all the previous edits to c:Commons:Help desk as read, but it didn't.

IKhitron added a comment.EditedJun 19 2019, 9:42 AM

Well, this time the lag is not twenty minutes any more. Eight Ten hours and counting.
And this time the problem is also in history pages and in API.

Well, this time the lag is not twenty minutes any more. Eight Ten hours and counting.
And this time the problem is also in history pages and in API.

Per the discussion on wikitech-l, this is/was due to T226109: Write incident report for jobs not being executed on 1.34.0-wmf.10.

Yann added a comment.Jun 20 2019, 5:22 AM

Hi, This also happened to me yesterday.

I'm seeing visited pages marked as unread on my Watchlist in 1.34.0-wmf.10.

Can someone still reproduce this problem, or did this get solved by T226109?

Can someone still reproduce this problem, or did this get solved by T226109?

Yes, it was happening when I posted:

I'm seeing visited pages marked as unread on my Watchlist in 1.34.0-wmf.10.

I can't reproduce the current issue. I've tested on several wikis, with two different accounts on two different browsers.

Can you please check the following? (copied from https://www.mediawiki.org/wiki/Help:Locating_broken_scripts)

Be sure you have an up-to-date configuration

  1. First, ensure your browser is up to date. MediaWiki features and some scripts are not supported by old browsers for safety reasons.
  2. Then, purge the cache for the page to force the page to be redisplayed from its source or scripts to restart.

Those two points solve most issues.

If you have a tool like "NoScript" or ad blockers installed on your web browser, then make certain that scripts are enabled for wikipedia.org, wikimedia.org, mediawiki.org, and wikidata.org.

Test if you have problems related to user scripts or gadgets

To test if your problem is linked to user scripts or gadgets, you can try to temporarily deactivate all on-wiki scripts at once.

To do so, add ?safemode=1 to the web address (URL) of the page on which you see the problem. Example: https://www.mediawiki.org/wiki/Special:Watchlist?safemode=1

If the URL already includes a ?, append &safemode=1 instead. Example: https://www.mediawiki.org/w/index.php?title=Special:Watchlist&safemode=1

If you still have problems on the page you are testing with the safe mode, and your browser is up to date, please report here.
If you don't have the problem anymore using the safe mode, it means you have an issue with a user script or gadget. You have then to identify the problem.

I believe the issue is solved. It hasn't happened to me in quite a while.

It happened me yesterday. I'll try to remember safemode checking next time. My browser is always up to date.

Same here, every week I get an issue with it, fully updated Firefox, no extensions at all, will try safe mode next time it will happen.

Titore added a comment.EditedJul 30 2019, 2:33 PM

It's happening again to me today, even in safe mode. Sometimes it looks like the entry finally gets unbold, only for it to become bold again after some time.

Confirming that.

Krinkle removed a subscriber: Krinkle.Aug 2 2019, 11:01 PM

Confirming that.

Have you followed the steps described above? T218511#5360423

Confirming that.

Have you followed the steps described above? T218511#5360423

Absolutely.

Happening for me right now, while using "&safemode=1"

Seen changes are showing in my watchlist even though I have it set to show only unseen.

Happening for me right now, while using "&safemode=1"
Seen changes are showing in my watchlist even though I have it set to show only unseen.

Sorry... more details: seen change is displaying not bold but is showing in the watchlist, despite filtering for only unseen changes.

(Instructions in T218511#5360423 followed.)

With safemode=1 and script-related browser extensions disabled.

Google Chrome Version 75.0.3770.142 (Official Build) (64-bit)

The change in the red box should not be bold since I have seen the edit. (I made it). Additionally, it shouldn't show up at all since the unseen changes filter is active.

None of the shown changes should be present. I have visited all of them, and the unseen changes filter is active.

Not sure why the first one is not bold but the other two are.

Joeyconnick added a comment.EditedAug 14 2019, 3:11 AM

This bug is going crazy right now

This is with &safemode=1 and no script-related extensions enabled

Reedy removed a subscriber: Reedy.Aug 14 2019, 8:02 AM

Something happened last night, the bug was there again and again.

And again... I've just visited both pages below (Kal Penn and The DUFF):

Yes, this is with &safemode=1

Bradv removed a subscriber: Bradv.Aug 28 2019, 3:09 PM
Dvorapa added a comment.EditedSep 9 2019, 9:01 PM

Today I got really annoying issues with marking changes as read/unread, I could not determine, whether I read the pages in my watchlist or not read as the bold markup was completely wrong/random everywhere (tested also in safemode)

It's doing it again. *sigh*