Probably related to the 17 hour replication lag for enwiki right now, similar to T362725. Root cause appears to be an issue with the replicas (T363077).

De-assigning until I can dedicate more time to this. Here's a summary of where I'm at though:

More information on how developers can react to the changes can now be found at mw:Trust and Safety Product/Temporary Accounts/For developers. I'll try to work on this, among other things, this week and next week.

Looks like this has been fixed. I can confirm that the CC BY-SA 4.0 text now shows up on the Android app. page-talk-page-subtitle in ruwiki PCS i18n data also reflects the latest from TranslateWiki. Marking this as resolved, unless something else comes up.

In T356704#9556128, @Tgr wrote:

If you want to debug what's happening, I think your best bet is checking out Quibble so you can run the test in the exact same environment it runs in on the CI servers, but with a debugger enabled.

Sorry for the relative silence! The year kicked off pretty busy for me. I'll be much more available now though.

This is an issue with RedWarn, as Ultraviolet doesn't have a right-click menu (as of now). We'll make sure this is fixed in reimplementation.

Can't seem to replicate this locally, or at least I know too little of the configuration to ensure that I'm replicating this properly. The page is undeleted with no issues. But the debug log it spat out corroborated what I wrote above.

I checked Flow but it was mostly localization and npm updates, so I wasn't ready to blame it just yet. In my head, this loop being interrupted by the teardown was pretty odd, and I focused on that instead.

Been investigating at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/997634 by putting a bunch of log statements in and I'm a bit stumped. Here's where I'm at:

You'll need the ORES extension installed and active, if it isn't already. The copyvio tag is, for some reason, attached to ORES being present in the wiki. Without it, PageTriage just skips searching for the copyvio tag entirely. Setup is here, to save you a few clicks.

Definitely related. Selecting the "copyvio" filter and any other filter on the new pages feed causes this issue to show up. The copyvio tag is JOINed separately from the rest of the tags, which in turn causes the reference to ptrpt_tag_id at ApiPageTriageList.php:577 to become ambiguous if both the copyvio tag and some other tag (newcomer, learner, etc.) have been requested.

Possibly related to T354894? The request URL matches the one on that task and it was opened just recently (though the logs here look like the underlying issue for that task).

Seems like it's happening when the "Copyvio"/"None" possible issue filter is paired with one of the "Were created by" filters (newcomer/learner/etc., except "Autopatrolled users" and "Show all"). This was reported for wmf.12 but it's still happening to me right now (seems like wmf.13 was deployed just minutes ago).

Caused by on-wiki changes, namely a flood of new version numbers on the Wikidata item for the page. At least it wasn't anything more serious.

We should also make sure to handle cross-origin requests (Access-Control-Allow-Origin), at least for Wikimedia sites. Otherwise, another external tool would be required to call these endpoints whenever they're needed from the browser side. In addition, we'll need to prevent cross-site request forgery (CSRF) through single-use tokens. That probably also needs an endpoint.

In T353076#9425326, @SD0001 wrote:

For mw.messages and mw.user.{options,tokens} which are indeed stable interfaces, we should be better off temporarily monkey-patching them so that each supports .has. In terms of JS cost, it should be a net positive as the three shims are together smaller than the mw.Map implementation.

Yeah, that seems like a sounder solution.

Backported, tested by @MPGuy2824, and messages are being posted now (check; link from @MPGuy2824). Thanks to everyone involved!

Added to Monday morning's backport window, but I don't have patroller/sysop on testwiki. @Novem_Linguae, @Soda: One of you might have to test the patch instead. Feel free to replace the requesting IRC nick or move the patch to a different window (n.b. I'll be unavailable starting 11:00 UTC as I travel for the holidays, so I won't be able to help test during the afternoon or late backport windows on Dec 18).

I thought mw.Map probably isn't covered by the frontend stable interface policy since it's a private class, but I realized that mw.messages, mw.user.options, and mw.user.tokens all use mw.Map. When the time comes that we shift those to using native JavaScript Maps, we will break a lot of gadgets which call .exists. We should tread carefully when executing this deprecation.

Yeah, revert seems easiest. In light of the above, it's probably better to switch from mw.Map to Map when the question of how .exists/.has will be handled is answered, or when we know that core can definitively support native JS maps. Discussing the changes to be made on core seems like it'll take time.

We should probably also add in tests to ensure that anything using mw.Map works with normal JS Maps. mw.Message apparently can't handle normal JS Maps, so that ended up breaking PageTriage (see T353571 for details).

That may be true, but if I'm not going to use an instanceof and will change mw.Message to call .has, it would break every other thing using an mw.Map since it doesn't have a .has function, and we can't search for all use cases doing this to be able to safely switch to using just .has (CodeSearch doesn't find uses in gadgets, userscripts, extensions not hosted on Gerrit, etc.). It's better to add that alias for now to avoid breaking things and for backwards compatibility, and then remove mw.Map as a whole later on, when we've announced its deprecation and we're ready to remove it (tracked in T353076).

Oh, there's actually two solutions to this. One is to revert the aforementioned commit and restore the use of a mw.Map, or change core to ensure that it works with normal JS maps. That itself has two solutions: change the behavior of mw.Message.exists depending on the map used using instanceof, or switch that function to use .has and then add a .has alias on mw.Map which just calls .exists. The latter seems best here, since it means other extensions/tools/etc. would be able to use native JS maps and not fall into the same issue.

@Novem_Linguae It seems to have been broken by this commit. .exists doesn't exist for native JS Maps, but only mw.Map maps. Should be a simple replacement; I'll have a patch filed in a sec.

We already have some of our repos at Ultraviolet on GitLab, so I can answer a few of @Novem_Linguae's questions based on my experiences working on it.

Thank you for reviewing (and getting them additional reviews) as well, @matmarex! :)

From what I've seen on the help desk (1 2 3 since my last comment here), VPT, and TEA (1 2), there's also a mentions of a Wikimedia\Rdbms\DBTransactionSizeError happening intermittently. The issue seems to appear on specific articles, with (as of now) no discernible pattern in what articles are impacted. It also just clears itself after some time, but there's been reports of this as recent as 10 minutes ago.

Also dropping here related request IDs from the help desk:

• c867a72e-ac5d-4b74-ad11-bd9084c0a12d
• 3228d684-e259-477d-a359-db71698e5abd
• bb5ad4fc-e7b2-411b-92a8-78201adada13

I've submitted https://gerrit.wikimedia.org/r/979440 to remove the dataType field in mw.Rest AJAX calls. This does, however, mean that any REST endpoint that returns an improper Content-Type header may cause JQuery to return a string for a JSON response. I'm working on https://gerrit.wikimedia.org/r/979441 to add Content-Type checking to REST API tests, so that this could be caught before it has any impact on the client. I'll take it out of WIP when I'm finished.

cc Parsoid, since this seems to be an issue specific to the newly-introduced endpoints in T350661.

Oh, looks like I haven't subscribed to any of those lists. 😅 Re: wikitech-l, Tech News is sent there every week, but it wouldn't hurt to also have a dedicated announcement for it so it's easier to find.

Think this might be worth a User-notice, given that it affects volunteer-run tools as well (can't definitively call this as I don't have analytics access). Tool maintainers need to update their package versions to properly filter out the canary events (to v2.1.0 for npm@wikimedia-streams and to whichever version closes T350756 for Pywikibot, when it gets closed). Volunteers like me also don't have access to the Slack announcement, so that probably won't be enough to get the word out to volunteer developers.

@Ottomata Also good here. Canary event filtering was released as part of v2.1.0 in wikimedia-streams, and around a month of time post-announcement should be enough for (maintained) dependent projects to update.

cc @Chlod for JavaScript wikimedia-streams client.

Hmm, perhaps allowing copying isn't the solution here, as it involves another button press. Two things I see that we could do here:

• Upon finding a new diff, store the saved edit summary, then redirect to the new diff. Upon pressing the rollback button again, pre-fill the text input box with the typed-out reason.
  • This only ever requires local storage (or perhaps IndexedDB), so not so expensive.
• We could also just steamroll revert the target user's edits, but this could cause some collateral damage.
  • This should only ever be considered if "rollback" was selected instead of "rollback-like" in the options.
  • This applies the revert immediately, unlike the first option which requires another page load.

Adding in Wikipedia-Android-App-Backlog here since the Android app is affected. Haven't tested on iOS (as I don't have an iOS device). Page Content Service only has two members and one watcher, so there may not be a lot of traction if this were the only tag on the task.

Will submit the patch in a bit, thanks for checking it out! 😀

I was the one screaming pre-emptively on le Discord, previous comment about this on T334238#9119834. I didn't even know that this was the right task to make the comment on. 🤦

Going to pop in here and stay ahead of breaking things for editors (since that seems to be the plan with T335513).

Comparing this with another widget which uses a popup (DropdownWidget), it looks like MenuSelectWidget.js:477 contains the code responsible for automatically flipping the direction that the menu appears when the dropdown is activated. It relies that ClippableElement is mixed in, however (since it needs to know whether or not the dialog will get clipped vertically, and that function is only exposed within ClippableElement). So the idea of making the calendar clippable/scrollable would solve both the issues with it being clipped when too close to the bottom of the screen and also allow the calendar to flip when the space below it is too little. A demonstration for this can be found with P51429. Not sure if this is the best solution for this yet so I've kept it a paste for now; do tell if this should be turned into a patch.

Looks like an upstream issue; attempting to save Q30834230 using Zotero causes an error. Something related to the author fields. Looking into this...

Done with this diff (approved by @Novem_Linguae, thanks!)

Patch for this filed and awaiting interface administrator review.

Vouching for Isochrone as the lead developer on Ultraviolet. We haven't moved much in a while and some extra hands to re-oil the machine would be great. Isochrone has a history of helping with tool documentation and development; no doubt they'd be a helpful contributor here.

Hi, @Jdlrobson! Sorry for the really late reply; I seem to have missed the email. Yes, the tasks above address all the concerns. Thank you very much!

This popped up recently on the Wikimedia Discord and I decided to check if it still holds up. Still does, it seems. The above digs still don't return MX records. Here's postfix log entries for an attempted email delivery earlier, which didn't succeed.

Seems like enwiki/s1 is back up again. I've also confirmed that the interface works properly again locally. Perhaps the error message on load can be removed now?

@Jdlrobson No problem! Happy to have helped. Thanks for the better patch!

wikitech:Deployments shows a few windows for today and tomorrow. The afternoon backport window is already underway; best not to interfere with that. The next window is in around 7 hours, but I'll be asleep by then. In any case, if deployment hits an issue, a revert should suffice, should you wish to ride that window. There's another window tomorrow at 07:00 (UTC), in case you need me online at the time of deployment.

I'd definitely be much happier if we moved over to using require for everything (heck, the current structure was a nightmare to debug), but this seems like a bigger effort that would take some time to test to make sure we didn't break anything. If there's nothing wrong from the analysis I posted above, given how unstable the toolbar currently is (considering the amount of people this bug has appeared for currently — and that's just the reported ones since we don't seem to have anything in Logstash), I think a temporary solution just to have this fixed immediately would be beneficial for NPP editors. Working towards a structure like in 917967 can follow immediately after.