Reported also in fiwiki https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(tekniikka)#Merkityissä_versioissa_taas_häikkää

cc @Reedy @Umherirrender @mszabo

Trying to bring this to the attention of someone who is able to help. There is a related pending patch in T379217

For the time the issue will be corrected, I hacked a little scipt that reviews new pages that were edited only by trusted users. Please forward the information to the bot owners in your wiki.
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/huwiki/temp_review.py

In T379218#10304174, @binbot wrote:

For the time the issue will be corrected, I hacked a little scipt that reviews new pages that were edited only by trusted users. Please forward the information to the bot owners in your wiki.
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/huwiki/temp_review.py

Coincidentally, I've created a bot yesterday to mitigate the older bug (page move) and also this one by reviewing the pages in real-time, based on EventStreams. If anyone wants, I can run it on their wikis as well (at the moment it's live on plwiki).

The extension is using the RevisionFromEditComplete hook. With T379152 there is an report about problems with change 5febca16489246a326e3b18471c8101dc3dd9358 (DomainEventDispatcher), this sounds very related to that task. The patch set is also listed as risky on the train task T375661

Could you rollback to previous version if there is no fix available soon?

T379152 is not a problem because FlaggedRevs doesn’t touch tags, but what I noticed is that the hook is called with a fresh WikiPage instance, so data on the ongoing edit (which is used by FlaggedRevs) is lost – this may be the culprit.

With the recent update there are other problems noticed that pages are not updating correctly after changes.
Again, could you rollback the changes?

In theory of course we could. In practice rolling back the train on a Monday is very rare (deployments on weekends are even rarer). And it was already called not a blocker at T375661#10301176

And we can't hold all other code changes hostage forever. Someone will need to investigate why this has happened and reproduce it, and either revert the cause or submit a fix. Holding everything else hostage in the mean time when a workaround is already known to exist (T379218#10305281) seems like an overreaction.

... although of course that's easy to say as someone who doesn't edit in any wikis affected by this bug, and has no decision-making authority.

In T379218#10307127, @Ipr1 wrote:

With the recent update there are other problems noticed that pages are not updating correctly after changes.

Could you please be more specific? The original bug report is clear (what you do, what happens), “other problems noticed” isn’t, making it nearly impossible to fix those “other problems” – one cannot fix a bug if they don’t know what the bug is.

There was one user who reported that after creating page from the red link the link in the original page doesn't change to blue. User said that he tried to purge the page cache and it didn't help. ( not sure if this was a single insident or if there was multiple ones )

The problem described by Ipr1 was that when adding a template to page which is included from another page (in this case creating a help page for a template) page doesn't update by itself without doing a purge anymore. (this can be replicated )

We can the bug ticket for this.

In T379218#10307172, @Zache wrote:

There was one user who reported that after creating page from the red link the link in the original page doesn't change to blue. User said that he tried to purge the page cache and it didn't help. ( not sure if this was a single insident or if there was multiple ones )

The problem is also reported in huwiki. After reviewing manually the unreviewed new articles they became blue from red.
So it may be related to this ticket.
https://hu.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Kocsmafal_(m%C5%B1szaki)&oldid=27586673#Rejt%C3%A9lyes_jelens%C3%A9g

New pages are unreviewed. Blue links stay red.
Huge problem in deWiki. It is probably a big problem in many wikis. Please fix this technical problem.

In T379218#10307172, @Zache wrote:

There was one user who reported that after creating page from the red link the link in the original page doesn't change to blue. User said that he tried to purge the page cache and it didn't help. ( not sure if this was a single insident or if there was multiple ones )

The problem described by Ipr1 was that when adding a template to page which is included from another page (in this case creating a help page for a template) page doesn't update by itself without doing a purge anymore. (this can be replicated )

Thanks for the extra info! I’m quite sure the two things you mentioned are connected (both cases are about dependent pages not “noticing” that the page they depend on has been created), but I’m not sure if it’s the same bug as the one reported in the description, especially given the test results detailed below.

In T379218#10307319, @Wargo wrote:

• Reproducible also on de.wikipedia.beta.wmflabs.org - you can test, not reproducible on Patchdemo.

The patch demo you created misses a number of extensions used on beta dewiki. I tried to include as many extensions as possible, though couldn’t reproduce it either. However, “as many as possible” means that quite a few extensions are still missing, which may make a difference:

• Not available on Patch Demo: AdvancedSearch, ApiFeatureUsage, ArticlePlaceholder, Babel, BounceHandler, Campaigns, Capiunto, CentralNotice, CirrusSearch, Collection, CommonsMetadata, Dashiki, DismissableSiteNotice, EasyTimeline, Elastica, ElectronPdfService, EntitySchema, ExternalGuidance, FancyCaptcha, FeaturedFeeds, FileExporter, GlobalCssJs, Global Usage, GlobalUserPage, Graph, InterwikiSorting, LabeledSectionTransclusion, LoginNotify, MediaModeration, MobileApp, NavigationTiming, NearbyPages, NetworkSession, Newsletter, OAuth, PageAssessments, PagedTiffHandler, ReadingLists, RealMe, RSS feed, SecureLinkFixer, SiteMatrix, TheWikipediaLibrary, TorBlock, TrustedXFF, TwoColConflict, VipsScaler, WebAuthn, WikibaseClient, WikibaseLexeme, WikimediaBadges, WikimediaCampaignEvents, WikimediaEvents, XAnalytics
• Available, but the patch demo creation failed when I tried to enable it: Chart (it failed to build something, probably it only works with the Kubernetes backend), StopForumSpam (IIRC it complained about some bad URL).

I also tried to reproduce the red link bug, but couldn’t either on Patch Demo or beta cluster. This is what I did:

• On Patch Demo:
  • As Alice (a reviewer / Sichter), added a link from Test_2 to Test_4, the edit was reviewed, as expected (since the previous version was reviewed);
  • As Bob (a user with no FlaggedRevs-related rights), created Test_4, the page remained unreviewed, as expected;
  • As Alice, reloaded Test_2, and the link turned blue, as expected.
• On beta cluster, as Tacsipacsi (a reviewer / Sichter):
  • Added a link from Test1 to Test_42, the edit was reviewed, as expected (since the previous version was reviewed);
  • Created Test_42, which unexpectedly remained unreviewed (this is the originally reported bug);
  • Refreshed Test1, and the link turned blue, as expected (i.e. the second bug didn’t come up).

In T379218#10307462, @Tacsipacsi wrote:

• On beta cluster, as Tacsipacsi (a reviewer / Sichter):
  • Added a link from Test1 to Test_42, the edit was reviewed, as expected (since the previous version was reviewed);
  • Created Test_42, which unexpectedly remained unreviewed (this is the originally reported bug);
  • Refreshed Test1, and the link turned blue, as expected (i.e. the second bug didn’t come up).

https://de.wikipedia.beta.wmflabs.org/wiki/Flaggedrevs-202411/next here it's red (at this moment).

Indeed, it’s red for me as well. However, my link turned blue within a minute on beta cluster (without doing any purge or null edit), so whatever the issue is, it seems to depend on multiple things – which isn’t surprising, given it’s a caching issue. It may also be that the bug has been fixed in the meantime (your example is three days old), although I tried to check out rMWf7f41ea950d581f3c78320d8d63f5465d960cb82 (the then-current master at 21:53, 7 November 2024 CET), and the new link still turned blue within a minute.

This could by fallout from T377229: Implement DomainEventDispatcher (baseline) which may have changed the order of execution of some hooks and deferred updates in a subtle way. Worth having a look...

Ping MW-Interfaces-Team

I just pushed a fix for T379152 that may also fix this issue, if it is caused by the issue that @Tacsipacsi noticed wrt using a fresh WikiPage instance: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1089708

In T379218#10309258, @daniel wrote:

if it is caused by the issue that @Tacsipacsi noticed wrt using a fresh WikiPage instance

Actually, I no longer think that’s the cause: if it was, the bug should be reproducible everywhere – however, I couldn’t reproduce it either on Patch Demo or locally when I tried yesterday. However, order of execution can very well be the cause (for example, it conflicts with another extension that isn’t installed for me locally and isn’t available on Patch Demo either), so there’s still hope.

Just FYI here as well: @Msz2001 is running a bot for auto-reviewing new pages. It is currently active on dewiki, fiwiki, plwiki, and plwiktionary. Also, thanks to Msz2001 for doing this.

• https://meta.wikimedia.org/wiki/User:MszBot

Pinging the Content-Transform-Team and specifically @cscott to have a look - the "red links stay red" issue sounds like it's related to RefreshLinksJob. I'm struggling to see the connection between that and autoreview, but both issues shoing up at the same time is suspicious. But perhaps we should have separate tickets for separate issues, even if we suspect that the cause might be the same...

Side note: Today is a holiday in the U.S., some people/teams may not respond before tomorrow.

I'm a little suspicious of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1088003 and maybe https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/681377 as possible causes.

In T379218#10309949, @cscott wrote:

I'm a little suspicious of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1088003 and maybe https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/681377 as possible causes.

The first one isn't merged, and the second on was merged 3 years ago...

I’ve just created https://de.wikipedia.beta.wmflabs.org/wiki/T379218, and it got autoreviewed, so it looks like rMW6965c29e74c0e1ddab344aab449e82c523b2a536 does indeed fix the originally reported bug! I couldn’t reproduce the red link problem even before that patch, so I haven’t tried it now.

In T379218#10309992, @Tacsipacsi wrote:

I’ve just created https://de.wikipedia.beta.wmflabs.org/wiki/T379218, and it got autoreviewed, so it looks like rMW6965c29e74c0e1ddab344aab449e82c523b2a536 does indeed fix the originally reported bug! I couldn’t reproduce the red link problem even before that patch, so I haven’t tried it now.

The fix hasn't yet be backported, so that can't be it... It's scheduled for the next window, in a couple of hours.

Doesn't beta cluster refresh based on the master branch every 10 minutes? Might not need a backport for the link in that post to have the latest patch.

{{ec}} It’s beta cluster, so it can very well be it. I checked Special:Version before performing the test, and core was at rMW05003f327c057f166bf4fbb751af5b3d58038cd6, a grandchild of your patch.

It’s beta cluster, so it can very well be it

Oh, right, on beta! Right! Sorry for the confusion.

Good to know that it seems to work :)

rMW6965c29e74c0: PageUpdater: restore call to RevisionFromEditComplete has been deployed to production, please re-test.
(Scap failed with T379589: scap backport fails at purgeMessageBlobStore.php with getaddrinfo failed but AIUI that shouldn't affect the success of the deployment.)

Looking at new pages in Russian Wikipedia by autoreview right holders, pages before 23:01 UTC had to be reviewed by a bot and pages created later get autoreviewed correctly. This seems to have been fixed then.

Yes, fixed

https://pl.wikipedia.org/wiki/Specjalna:Ostatnie_zmiany?hidebots=1&hidepageedits=1&hidecategorization=1&hideWikibase=1&hidelog=1&hidenewuserlog=1&limit=100&days=30&enhanced=1&flaggedrevs__needreview_color=c5&flaggedrevs__reviewed_color=c2&flaggedrevs__notreviewable_color=c3&tagfilter__bot-reviewed_color=c1&urlversion=2