PRs:

1. Update all ESLint-related dependencies #413
2. Update all Jest-related dependencies #414
3. Update vue-tsc #415
4. Update all PostCSS/Stylelint-related dependencies #416
5. Update further dependencies #417

I consider the wdio related updates out of scope here as the browser tests are being investigate/ worked on in parallel anyway (also just trivially updating broke lots of things). Therefore we only need to update husky and lint-staged here.

PRs:

1. Update all ESLint-related dependencies #558
2. Update all Jest-related dependencies #559
3. Update wmde/wikit-vue-components #560
4. Update PostCSS #561
5. Update sass*, axios and typescript #562
6. Apply npm audit fix #563

https://github.com/wmde/wikidata-mismatch-finder/pull/550

Moving this to verification, as I suppose this is all we're going to do here in terms of edge case handling.

I think what happened here (because it also initially happened to me), is that the horizontal scrollbar is not expected to be at the very bottom of the entire page (meaning to reach it you need to scroll through the whole table).

This is indeed still part of cognates sites (and some pages are part of cognate_pages):

In T44783#4902315, @Lucas_Werkmeister_WMDE wrote:

[…]
However, changes to sitelinks don’t seem to be as common as T44783#2587386 makes it sound, unless I’m mistaken: according to this Quarry query, there were around 100k sitelink changes in the past week, compared to over five and a half million changes overall, i. e. 1.8% of changes. (Though this might miss wbeditentity edits that only touched the sitelinks.)

Since I don’t think we currently need any optimizations to change dispatching, I’m lowering the priority of this task a bit: we can do this optimization if needed, but it’s not really necessary at the moment.

I've just updated PropertySuggester_update with the latest instructions.

I have not fully finished this yet, but one thing to note: The return if rc_this_oldid is <= 0 is no longer needed. This was added back when changes were saved to wb_changes and later loaded by revision id (used to be ChangeLookup::loadByRevisionId), but nowadays the changes are only identified/ updated by their own id.

This is fully done now once the above patch is merged (except for T326681: axe-core 4.6 makes new-lexeme-special-page a11y tests fail).

In T326681#8516773, @Lucas_Werkmeister_WMDE wrote:

Hm, if I understand MDN: aria-controls correctly, Wikit should set the input’s aria-controls to the same ID as the aria-owns? (I.e., the input should both control and own the “combobox popup”.)

Still to do:

1. Look into the axe-core update (4.5.2 -> 4.6.2) which breaks the tests
2. Review the dependabot PRs
3. Update the submodule version in WikibaseLexeme

In T313027#8428371, @noarave wrote:

[…]

• We should make sure the right condition gets called by the following endpoints:
  • wbeditentity
  • wbsetdescription
  • Special:SetDescription
  • Special:SetLabelDescriptionAliases
  • Special:NewItem
  • Special:NewProperty

PR chain:
https://github.com/wmde/wikidata-mismatch-finder/pull/463
https://github.com/wmde/wikidata-mismatch-finder/pull/464
https://github.com/wmde/wikidata-mismatch-finder/pull/465
https://github.com/wmde/wikidata-mismatch-finder/pull/466

I wonder if we should still report the most lagged instance in that case (or also the median one or maybe none at all)?

LogEventsList::getTitleInputDesc already gets the title input, it "just" needs to be title formatted and passed as default.

I just did the final clean up of this (see T300770#8286874/T300770#8290231): We had 18,961 invalid entries for commons, 84 for enwiki and 5 for enwiktionary (and none for other wikis).

WDQS maintenance occurred during the time frame in which these errors occurred, making this a likely cause of Prometheus returning unexpected data.

This was almost certainly a hiccup caused during the deployment of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikidata.org/+/845016.

Tests are good again: https://integration.wikimedia.org/ci/job/termbox-pipeline-test/274/

I managed to reproduce this locally, and after some poking I managed to nail this down to: https://github.com/vuejs/core/issues/5063

@valerio.bozzolan Exactly: When focus is lost from the input but the preview got clicked on (mousedown), we left it open. But as the map zoom links prevented the mousedown events from bubbling up through the DOM, we couldn't catch clicks on them that way.

Current plan:

1. Merge and deploy https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikidata.org/+/841136
2. Get https://gerrit.wikimedia.org/r/c/operations/puppet/+/841148 merged and deployed
3. Merge https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikidata.org/+/552544 (can be either deployed per hand to actually see the impact live or we can just let it go with the train)

This is fully deployed in production now!

Today when deploying we noticed that sometimes old entries (with positive namespace id as value) can slip back in when a link update is performed from an older parser output (from parser cache). Given this happens rarely, we decided to just ignore this for now and run the maintenance scripts again in a month to fix these cases.

The deploy window today didn't suffice and, although only the biggest wikis are done, about 2/3rds of the rows have been update. I've schedule a new window for tomorrow 08:30–10:00 UTC (10:30–12:00 UTC+2).

Deploy/ migration of the new page prop format to all Wikis scheduled for Wednesday, October 5, 08:30–13:00 UTC (10:30–15:00 UTC+2).

Today we successfully deployed the new format (inverted namespace number as pp_value/pp_sortkey) to the "wikidataclient-test" wikis.

Given this is merged now, I will migrate the test wikis this week (probably Thursday) and the rest sometime next week (Tuesday?). I'll keep this task updated.