FF 118.0.1
I would expect more details about the individual alerts/notifications from the other wikis to appear upon expanding
| Reedy | |
| Oct 10 2023, 3:49 PM |
| F38190130: Screen Recording 2023-10-10 at 16.46.46.mov | |
| Oct 10 2023, 3:49 PM |
| F38190125: Screenshot 2023-10-10 at 16.44.46.png | |
| Oct 10 2023, 3:49 PM |
FF 118.0.1
I would expect more details about the individual alerts/notifications from the other wikis to appear upon expanding
Confirming, the call to https://www.mediawiki.org/w/api.php?action=query&format=json&formatversion=2&meta=notifications¬sections=alert¬format=model¬limit=25¬prop=list%7Ccount%7CseenTime&uselang=en¬wikis=metawiki¬filter=!read¬bundle=true&_=1234567890123 returns {"batchcomplete":true,"query":{"notifications":{"list":[],"rawcount":0,"count":"0"}}}
The only things that I can see that could be anywhere possible causes/suspect patches would be rECHO18ed307c39de: ForeignWikiRequest: Ensure fetching CSRF tokens uses unique CentralAuth tokens/rECHOc3c3aed4dc44: ForeignWikiRequest: Specify formatversion, errorformat from @matmarex
Which is probably xref T342201: MediaWiki\Extension\Notifications\Api\ApiEchoUnreadNotificationPages::getUnreadNotificationPagesFromForeign: Unexpected API response from {wiki}... This task being the user facing impact, but that task being something related to the underlying error...
And that means it's not @matmarex's patches, but probably "fallout" from the DC switchover (and how MW is handling some of it).
This seems to be wiki-specific. For example, if I have an unread notification at https://meta.wikimedia.org/, it will not show up as a cross-wiki notification on https://www.mediawiki.org/, but it *will* show up on https://en.wikipedia.org/.
This is T223413: Broken (empty) cross-wiki notification when using $wgLocalHTTPProxy (e.g. on Kubernetes) and has been broken for a very long time. It seems specific to mediawiki.org and fully deterministic, so not related to the unreliability of centralauthtoken.