As for rollback links, there is also T122546: Cache rollback edit counts shown on recent changes, but I have had some doubts about whether it would have the desired effect.

While this proposal seems straightforward to implement, I have some doubts.

DiscussionTools have adopted this, too.

This should be easy to fix, thanks to the $isRevert flag.

Indeed, new text has always checked only for the "identification" part in the signature, regardless of the timestamp:

Perhaps @tarlocesilion can tell if they can access all their notifications again.

Note that to prevent the fatals (original report), the other patch for Echo is also needed. But that may be out of scope for Wikibase people.

E.g. Czech (cs). https://www.wikidata.org/wiki/Special:SetLabel?uselang=cs is titled "Nastavit štítek pro položka/vlastnost". This is grammatically incorrect.

Smoke test: when wmf.2 reached group1 (Wikidata et co.), the event insertion rate immediately decreased, yet the notification rate stayed the same: https://grafana.wikimedia.org/d/onyD7cOMk/echo-extension-notification-baseline-track.

I guess this also falls under T378876.

This is still being reported in 1.44.0-wmf.1:

[21498af3-3efb-4302-90ae-30b61fbc8856] 2024-11-01 10:07:48: Kritická výjimka typu „InvalidArgumentException“

Users on cs.wikipedia.org report similar problems: https://cs.wikipedia.org/wiki/Wikipedie:Pod_l%C3%ADpou_(technika)#Vnit%C5%99n%C3%AD_chyba.
Phatality ID: 2948b48d-da1e-43c7-9f8a-f1d1b759bea3.

Another example: https://www.wikidata.org/w/index.php?title=Q1747098&diff=2264753419.

1. H:i, j. xg Y.
2. H:i, j. M. Y.
3. H:i, j. n. Y.

The transformation happens on-the-fly, it has no impact on the database storage. I wonder if "Undo 123456789 ..." can be understood by everyone.

I think I found it. See ConsequencesExecutor::removeRedundantConsequences. It remove[s] "disallow" if a dangerous action will be executed, and "blockautopromote" is one of them. In fact, the method is confident that the action will be executed, but there is no guarantee. Indeed, BlockAutopromote::execute contains at least one code path that can lead to not blocking autopromotion (IP addresses).

In T194402#10237108, @Lucas_Werkmeister_WMDE wrote:

the restore message replaced an earlier message in Wikibase (introduced in 2012) which didn’t have the talk page link, so I think that’s why the messages are the way they are

Looks like either T102420 or T235363.

I've just discovered a bug in one of the dashboards: T375415: Echo notification stats are broken.

The least-effort solution (without defining new services and responsibilities) seems to be to simply pass around the same Event instance and insert it only when its id is needed for reference (Notification, Notifier). NotificationJob (see also T101050) should also be changed to not require the id, the event should be serialized for the job payload instead.

I assume this is done, but I couldn't verify it.

Came to say this would have been handy many times already...

It seems tricky, but it can rewritten to something like this (maybe it can be generalized to a utility function?).

Then, the workaround is to either remove the link or change it to [[:User:$1|$1]] (note the colon).

What kind of notification is it? "your edit has been reverted" or "mention in summary"?

DiscussionTools implement that using the discussiontools-signature-prefix message. I also found sig-text (core) and wikieditor-toolbar-help-content-signaturetimestamp-syntax (WikiEditor (2010)).

Though this can't be reproduced in markup here, the title attributes (tooltips) of the timestamps are also wrong: they're set to the name of the category, not the linked pages themselves.

You are right. The root problem is we let it insert a nonexisting user as an IP address. And it needs to be fixed.
It cannot be fixed using "interwiki pointing" you mention, though. Because "interwiki pointing" would not create the user, either.

Noticed right now, too. Apparently, RevisionStore::getRevisionSizes cannot load from archive.

After another similar report T372556: Article creation not recorded in RecentChanges database table, I tried to find all possibly missing recent changes entries to look for clues and how often it probably happens. I did it on Wikidata as it's the most heavily edited wiki.

I agree having a wrapper around DataSite.save_claim would be useful. I just disagree with the proposed solution. There is no point in adding this method to MediaInfo since DataSite.save_claim does not need the entity object at all.

We don't have ItemPage.changeClaim either. DataSite.save_claim is wrapped around by Claim.changeRank, and there is also Claim.changeClaim_target which should already work for all entity types.

This feature has been removed.

Thanks! The bots are now indeed back.

the In the news section still starts with July 31. Not sure what's up with that.

This morning (CEST), I visited my favorite wiki's main page and was shown a cached version from yesterday (2024-07-31). So I took a snapshot of the debug comment:

<!-- 
NewPP limit report
Parsed by mw‐web.eqiad.main‐5ffbbd4f55‐hlpc7
Cached time: 20240731111040
Cache expiry: 3600
Reduced expiry: true
Complications: [no‐toc]
CPU time usage: 0.345 seconds
Real time usage: 0.468 seconds
Preprocessor visited node count: 4056/1000000
Post‐expand include size: 53226/2097152 bytes
Template argument size: 13576/2097152 bytes
Highest expansion depth: 15/100
Expensive parser function count: 16/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 2104/5000000 bytes
Lua time usage: 0.060/10.000 seconds
Lua memory usage: 1460527/52428800 bytes
Number of Wikibase entities loaded: 0/400
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00%  276.223      1 -total
 80.62%  222.704      1 Šablona:Nejnovější_aktuality
 39.88%  110.165     11 Šablona:Aktualita_úmrtí
 38.10%  105.249     11 Šablona:Aktualita_úmrtí/výstup
 28.34%   78.286      8 Šablona:Aktualita
 25.48%   70.372     15 Šablona:Flagicon
 18.04%   49.819     22 Šablona:Delink
 10.09%   27.877      1 Šablona:Nejnovější_aktuality/Box_s_odkazy
  9.31%   25.713      1 Šablona:Vseznam
  8.73%   24.119     15 Šablona:Flagicon/core
-->

In T367638#10023959, @Wargo wrote:

In T367638#10022975, @matej_suchanek wrote:

If we cannot assume the user exists locally, what should be done?

Or some interwiki pointing. The action is done using account on external wiki, so that account should be linked anyway. To be handled by CentralAuth and their hooks?

It seems two problems meet here:

Could it be accounts created by email? I.e. log_action = 'byemail'. Or log_action = 'create2', too.
In these cases, the actor is the user who creates the account, not the account created.
Try query for log_namespace = 2 AND log_title = REPLACE(user_name, ' ', '_') instead.