Confirmed in finnish Wikipedia too. Same regression exists in watchlist and Recentchangeslinked page too.

Also apparent in trwiki and enwikibooks.

Also in Arabic wiki! T164068

This could have been caused by https://phabricator.wikimedia.org/rEFLRad612350b61786b00897f1dec44bdfac5c8ab349

As Paladox pointed out, https://phabricator.wikimedia.org/rEFLRad612350b61786b00897f1dec44bdfac5c8ab349 might be related?

Russian Wiki has the same problem. "!" sign had been dissapeared from RecentChanges and Watchlist, also.

Change 350968 had a related patch set uploaded (by Mattflaschen; owner: Mattflaschen):
[mediawiki/extensions/FlaggedRevs@master] Fix FlaggedRevs RC (RecentChanges and Watchlist) line indications

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

Change 350968 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@master] Fix FlaggedRevs RC (RecentChanges and Watchlist) line indications

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

Could this be fixed earlier by any chance? This is basically turning off the most efficient way of reviewing process (active users checking their watchlist), it is hurtful for the whole projects not to have these links and notices even in 1 day, not even talking about 10.

In T164049#3223733, @stjn wrote:

Could this be fixed earlier by any chance? This is basically turning off the most efficient way of reviewing process (active users checking their watchlist), it is hurtful for the whole projects not to have these links and notices even in 1 day, not even talking about 10.

As answered on IRC, this won't be deployed on the weekend (just like nothing else is) and due to the DC switchover likely neither next week. However, I'd also suggest to SWAT this on Monday, May 8 instead of waiting this to be rolled out with the train (which would mean delay until Thursday, May 11 for almost all Wikipedias).

Change 351093 had a related patch set uploaded (by Mattflaschen; owner: Mattflaschen):
[mediawiki/extensions/FlaggedRevs@wmf/1.29.0-wmf.21] Fix FlaggedRevs RC (RecentChanges and Watchlist) line indications

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

In T164049#3223739, @EddieGP wrote:

As answered on IRC, this won't be deployed on the weekend (just like nothing else is) and due to the DC switchover likely neither next week. However, I'd also suggest to SWAT this on Monday, May 8 instead of waiting this to be rolled out with the train (which would mean delay until Thursday, May 11 for almost all Wikipedias).

Yes, we've been planning to deploy it then. It's now officially scheduled for 1300 UTC Monday May 8th.

I apologize for the bug, and the inconvenience of the deployment freeze.

As you know (but in case anyone else sees the bug), you can partially workaround the issue by hiding reviewed changes.

In T164049#3223830, @Mattflaschen-WMF wrote:

In T164049#3223739, @EddieGP wrote:

As answered on IRC, this won't be deployed on the weekend (just like nothing else is) and due to the DC switchover likely neither next week. However, I'd also suggest to SWAT this on Monday, May 8 instead of waiting this to be rolled out with the train (which would mean delay until Thursday, May 11 for almost all Wikipedias).

Yes, we've been planning to deploy it then. It's now officially scheduled for 1300 UTC Monday May 8th.

Thanks!

Some stats how bug is effected to reviews using Quarry

• Rewiews per day (quarry: 18306)
• Reviewers per day (quarry: 18307)

Well, from our (Wikipedians - recent changes patrollers) point of view, the situation is as follows: RC does not work as expected. It's emergency situation. In emergency we requre to restore the normal condition ASAP. Scheduled May 8th is a much too late.

In T164049#3226553, @WTM wrote:

Well, from our (Wikipedians - recent changes patrollers) point of view, the situation is as follows: RC does not work as expected. It's emergency situation. In emergency we requre to restore the normal condition ASAP. Scheduled May 8th is a much too late.

I really understand that this just sucks and is urgent, though I wouldn't call it an emergency. I (and as far as I know most people around here) call something an "emergency" when it's something worth to wake up the operations team for in the middle of the night. Usually that is when there is the whole site down for all users (or at last a large part of them). So I can't really agree with your choice of "emergency" here - especially as this can be made much less awful with the workaround to hide reviewed edits.

But besides the choice of words, it's undeniable urgent. We're aware of that and that is why it's been scheduled to the next anyhow possible deployment window - that would usually have been at 1300 UTC Monday, May 01. We're in the really unfortunate situation that the WMF is switching datacenters this week and hence blocked every deployment. (BTW, that is for a good reason, as every deployment has the risk of making things even worse - but agreed, it just sucks for this very problem.) So as it is, the next time when we can do something is May 8th, 1300 UTC. Which is exactly the time at which we will be doing something.

You can like that or don't like that we're having really bad luck that this regression comes up at this time. Personally I think it really sucks. I really understand that you feel the developers should have to deal with that earlier. That said, we'll still just have to deal with it. Changing the tasks priority or stating again how urgent this is won't help much. Feel free to damn the developers for breaking stuff if you feel so ;) - but please do so with knowing that they're doing all they can to solve this as fast as possible and are sorry that they can't do faster.

With issues like this it would’ve been best to abstain in the future from any major releases and changes (besides bug fixes) on the week before the week when no changes can be deployed. Situation when there could be a major change that is wrong and can’t be fixed in an urgent way is just wrong by itself.

@WTM Quick temporary fix for recent changes list is to add link to recent changes list with hideReviewed=1 in sidebar (see diff)

Also if the rcpatrol is enabled then you could use rcpatrols css-classes for highlighting the pending changes in recentchanges and watchlist. In fiwiki we last year enabled the rcpatrol for API and patroled flag support, but revieweing is still done using FR. Setup is pretty much that we have identical patroller and reviewer user groups and the patrolling interface is hidden via CSS. Now when the sight links are gone we removed some of the hiding so that we can see which edits are reviewed and which are not.

Change 351093 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@wmf/1.29.0-wmf.21] Fix FlaggedRevs RC (RecentChanges and Watchlist) line indications

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

Mentioned in SAL (#wikimedia-operations) [2017-05-02T03:10:31Z] <mattflaschen@naos> Synchronized php-1.29.0-wmf.21/extensions/FlaggedRevs/: Urgent deploy: Fix FlaggedRevs fatal, and also a filter issue: T164096 and T164049 (duration: 00m 56s)

Deployed to production, and verified working on German Wikipedia (it's deployed everywhere though).

I fixed T164096: 503 "Service Unavailable" error on Special:RevisionReview, which is an unrelated fatal. However, since they're the same extension and one is a fatal, we decided to make an exception and deploy both.

Checked the presence and functionality of links on arwiki, ruwiki, plwiki, dewik, trwiki, and enwikibooks (wmf.21).

QA Recommendation: Resolve

In T164049#3220830, @alanajjar wrote:

Also in Arabic wiki! T164068

Fixed in ar.wiki. Thanks