In T292626#7619369, @STran wrote:

cc @Prtksxna ASN is in the designs but no one has access to view it atm 😅 I made an assumption but should ipinfo-view-full see ASN? Should ipinfo-view-basic?

1. The fallback chains specified in the message files should be considered part of the software, rather than something to be modified by wiki administrators

The reason modifying the fallback chain is just used for simulating the situation.

The recommendations I get (both from the production API and locally) for the pre-edit version of the page:

{
  "context_after": "u na násle",
  "context_before": "ší přesun ",
  "link_index": 2,
  "link_target": "Kurzor",
  "link_text": "kurzor",
  "match_index": 0,
  "score": 0.708010733127594,
  "wikitext_offset": 424
}
{
  "context_after": "akban.\n\nA ",
  "context_before": "Vitesse”) ",
  "link_index": 8,
  "link_target": "Forgóváz",
  "link_text": "forgóváz",
  "match_index": 2,
  "score": 0.820939838886261,
  "wikitext_offset": 6373
}

(I used this helper script FWIW: P18742 I couldn't reproduce the arwiki recommendation; presumably the arwiki dataset has been regenerated since then.)

In T293962#7594596, @iamjessklein wrote:

Write a subject and paragraph, go to the legacy view, type something then return to the new experience...

Great spot, @iamjessklein. @DLynch, @matmarex, @VPuffetMichel, and I talked about this on Wednesday and arrived at the following:

1. We will address the issue of how –if at all – changes drafted in the New Discussion Tool and legacy experience are retained when moving back and forth between the two in T299270
   • Said another way: resolving the issue T299270 now describes does *NOT* need to block this ticket proceeding through QA.
2. We will consider the broader question of, "In what cases do we show the browser "abandon changes" warning dialog and in what cases do we show the 'native' OOUI abandon changes warning dialog?" in T299271

You are correct, this is a different error but the end result is the same, no filename in written field:

after the upload dialogue, you come back to the form, where NO filename is written in the field
when you save the page, no edit has been done, thus no reference to the file is stored on the page

I am using MW 1.35.1, PF 4.9.4 since 5.3.3 does not have PFGoogleMapsInput::getName() which I use for my forms to display a GoogleMap to grab a WKT Geography. I even grabbed REL1_35 (4.9.4) from git but that has the $this-> error (replacing with wfMessage in those 2 functions (getInitialPageText and getExistsWarning) resolves that issue.
I guess maybe something else is broken since Edit with Form doesn't show up on a form created. https://imgur.com/a/zCBA4jP

refreshLinks is running against enwiki, commonswiki in tmux under my name.

@iamjessklein: what – if any – concerns do you have about moving forward with the "Desired" behavior described in the task description as a first step?

Mentioned in SAL (#wikimedia-operations) [2022-01-15T03:05:26Z] <legoktm> started refreshLinks --dfn-only via systemd units for s7-s8 (T299244)

Mentioned in SAL (#wikimedia-operations) [2022-01-15T03:01:32Z] <legoktm> started refreshLinks --dfn-only via systemd units for s2-s6 (T299244)

In T299244#7623650, @Umherirrender wrote:

In T299244#7623554, @Legoktm wrote:

• Even after the revert is deployed, we need some cleanup script or queries to reset the links table.

That seems to be refreshLinks.php with --dfn-only, there is periodic job already, which could be started out of the row.

Mentioned in SAL (#wikimedia-operations) [2022-01-15T02:55:10Z] <legoktm> started mwscript refreshLinks.php --wiki=commonswiki --dfn-only (T299244)

I think this task is actually not needed?

Mentioned in SAL (#wikimedia-operations) [2022-01-15T02:54:14Z] <legoktm> started mwscript refreshLinks.php --wiki=enwiki --dfn-only (T299244)

In T299244#7623554, @Legoktm wrote:

• Even after the revert is deployed, we need some cleanup script or queries to reset the links table.

Change 753194 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Add tests for bullet indentation

https://gerrit.wikimedia.org/r/753194

Change 754054 had a related patch set uploaded (by Scardenasmolinar; author: Scardenasmolinar):

[operations/mediawiki-config@master] Change TheWikipediaLibrary editcount

https://gerrit.wikimedia.org/r/754054

This was fixed per change 737702 which can keep the old local values, but restored due to T298614.
I finally convinced myself that saving global values to local database positively is good, since we can provide a better experience without changing a lot of behavior after the user deglobalized some preferences.

Should the delete be in the same batch or its own loop? Should we add a --dry-run option to just print out what'll get deleted?

OK, provisionally we think that this is 'fixed' (no longer making things worse) in current production, but (a) the counts are still going to be wrong until they naturally drift towards correctitude or an outside force like a script fixes them, and (b) the code isn't reverted or fixed in the dev branch so it'll break prod in the same way next week unless it's fixed. Un-tagging as a blocker from this week's train.

According to https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar, Monday should be a "no deployments" day.

Change 753818 merged by Ottomata:

[operations/puppet@production] Absent network_flows_internal druid jobs

https://gerrit.wikimedia.org/r/753818

Mentioned in SAL (#wikimedia-operations) [2022-01-15T00:57:59Z] <dduvall@deploy1002> rebuilt and synchronized wikiversions files: all wikis to 1.38.0-wmf.17 refs T293958

Change 754053 merged by jenkins-bot:

[operations/mediawiki-config@master] all wikis to 1.38.0-wmf.17 refs T293958

https://gerrit.wikimedia.org/r/754053

Change 754053 had a related patch set uploaded (by Dduvall; author: Dduvall):

[operations/mediawiki-config@master] all wikis to 1.38.0-wmf.17 refs T293958

https://gerrit.wikimedia.org/r/754053

Mentioned in SAL (#wikimedia-operations) [2022-01-15T00:52:32Z] <dduvall@deploy1002> Synchronized php: group1 wikis to 1.38.0-wmf.17 refs T293958 (duration: 00m 52s)

Mentioned in SAL (#wikimedia-operations) [2022-01-15T00:51:39Z] <dduvall@deploy1002> rebuilt and synchronized wikiversions files: group1 wikis to 1.38.0-wmf.17 refs T293958

Another consideration: We're using camelCasing for the prop name in events like "update:modelValue" in JavaScript and TypeScript code, but a kebab-case version must be used in the template. Should we use the kebab-case version everywhere?

Change 754052 had a related patch set uploaded (by Catrope; author: Catrope):

[design/codex@main] build: Enforce kebab-case for component names and event names

https://gerrit.wikimedia.org/r/754052

Change 754051 merged by jenkins-bot:

[operations/mediawiki-config@master] group1 wikis to 1.38.0-wmf.17 refs T293958

https://gerrit.wikimedia.org/r/754051

Change 754051 had a related patch set uploaded (by Dduvall; author: Dduvall):

[operations/mediawiki-config@master] group1 wikis to 1.38.0-wmf.17 refs T293958

https://gerrit.wikimedia.org/r/754051

Mentioned in SAL (#wikimedia-operations) [2022-01-15T00:46:37Z] <jforrester@deploy1002> Finished scap: Revert "LinksUpdate refactor" and follow-ups for T299244 re. T293958 (duration: 03m 58s)

Mentioned in SAL (#wikimedia-operations) [2022-01-15T00:46:37Z] <jforrester@deploy1002> Finished scap: Revert "LinksUpdate refactor" and follow-ups for T299244 re. T293958 (duration: 03m 58s)

Mentioned in SAL (#wikimedia-operations) [2022-01-15T00:42:39Z] <jforrester@deploy1002> Started scap: Revert "LinksUpdate refactor" and follow-ups for T299244 re. T293958

Mentioned in SAL (#wikimedia-operations) [2022-01-15T00:42:39Z] <jforrester@deploy1002> Started scap: Revert "LinksUpdate refactor" and follow-ups for T299244 re. T293958

In T299244#7623552, @Jdforrester-WMF wrote:

In T299244#7623527, @Umherirrender wrote:

In T299244#7623506, @Jdforrester-WMF wrote:

Some quick thoughts on eyeballing the code:

• The issue is presumably coming from LinksTable::getFromConds() line 353: return [ $this->getFromField() => $this->getSourcePageId() ];
• LinksTable::getSourcePageId() line 276 returns the getId() of the private PageIdentity $sourcePage
  • PageIdentity::getId() -> Title::getArticleID() which shouldn't return 0 except if canExist() returns false?
• LinksTable::injectBaseDependencies() is meant to set this, and is meant to be called by the factory on instantiation.

As time of the constructor of LinksDeletionUpdate and parent LinksUpdate the page id is set. But it is used on call of LinksUpdate::doUpdate and than the page id of the title is reset and LinkCache/PageStore also missing the page.
Caches are cleared to make the page showing redlinks. The clean up in the LinksUpdate is deferred after all of that and has to store its id to make sure it deletes the correct things. That was hold by LinksUpdate::$mId in the past (and could be done also now), but the new code used a page identity which is aware of all the changes done in the meantime, possible even when cloned due to refresh code.

If the page id is copy over to a new object it seems to work. Title::toPageIdentity is documented for this with: "The ProperPageIdentity returned by this method is guaranteed to be immutable." Which sounds great (at least at the moment).

---

[Linter extension was affected similiar, fixed some days ago - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/752743]

Aha, that makes sense. Thanks for the analysis and the patch. For now we're going to deploy the revert, to give Tim/Daniel/CPT time to review your fix rather than deploying it without their input.

I've uploaded a patch that relaxes the CSP rules for doc.wikimedia.org to allow these requests, but I think these should be reviewed and approved by the Security-Team before we make that change. (cc @sbassett who was involved in setting these CSP rules in 2019)

Change 754048 had a related patch set uploaded (by Catrope; author: Catrope):

[operations/puppet@production] doc.wikimedia.org CSP: Allow XHR requests to Wikipedia and Wikidata

https://gerrit.wikimedia.org/r/754048

Summarizing the current status from IRC:

• We're deploying the revert to wmf.17, and have moved the train back to wmf.16 temporarily while it gets synced out in a non-atomic way. After testing we'll move forward again to wmf.17.
• Umherirrender's analysis/patch looks good, but we want to leave that for Tim to review and if there are any other follow-ups from this.
• Even after the revert is deployed, we need some cleanup script or queries to reset the links table.

Change 754046 merged by jenkins-bot:

[mediawiki/core@wmf/1.38.0-wmf.17] Revert \"LinksUpdate refactor\" and follow-ups

https://gerrit.wikimedia.org/r/754046

In T299244#7623527, @Umherirrender wrote:

In T299244#7623506, @Jdforrester-WMF wrote:

Some quick thoughts on eyeballing the code:

• The issue is presumably coming from LinksTable::getFromConds() line 353: return [ $this->getFromField() => $this->getSourcePageId() ];
• LinksTable::getSourcePageId() line 276 returns the getId() of the private PageIdentity $sourcePage
  • PageIdentity::getId() -> Title::getArticleID() which shouldn't return 0 except if canExist() returns false?
• LinksTable::injectBaseDependencies() is meant to set this, and is meant to be called by the factory on instantiation.

As time of the constructor of LinksDeletionUpdate and parent LinksUpdate the page id is set. But it is used on call of LinksUpdate::doUpdate and than the page id of the title is reset and LinkCache/PageStore also missing the page.
Caches are cleared to make the page showing redlinks. The clean up in the LinksUpdate is deferred after all of that and has to store its id to make sure it deletes the correct things. That was hold by LinksUpdate::$mId in the past (and could be done also now), but the new code used a page identity which is aware of all the changes done in the meantime, possible even when cloned due to refresh code.

If the page id is copy over to a new object it seems to work. Title::toPageIdentity is documented for this with: "The ProperPageIdentity returned by this method is guaranteed to be immutable." Which sounds great (at least at the moment).

---

[Linter extension was affected similiar, fixed some days ago - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/752743]

In T296753#7622157, @schoenbaechler wrote:

Thanks both! Replies below 👇

Since the title uses the link color, the RESET TO DEFAULT button is de-emphasized and perceived as another section title. We’re doing this already within languages, so I suggest that @cooltey applies the same style to Quick actions and Menu:

→ This feedback is emphasized by the design team, namely @bmartinezcalvo @cmadeo @Volker_E

@schoenbaechler's proposal looks harmonious and great to me!

Noting possible relationship to T6469

The same issue affects the Codex demo at https://doc.wikimedia.org/codex/main/components/lookup.html#with-fetched-results:

In T299244#7623506, @Jdforrester-WMF wrote:

Some quick thoughts on eyeballing the code:

• The issue is presumably coming from LinksTable::getFromConds() line 353: return [ $this->getFromField() => $this->getSourcePageId() ];
• LinksTable::getSourcePageId() line 276 returns the getId() of the private PageIdentity $sourcePage
  • PageIdentity::getId() -> Title::getArticleID() which shouldn't return 0 except if canExist() returns false?
• LinksTable::injectBaseDependencies() is meant to set this, and is meant to be called by the factory on instantiation.

Change 754047 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] Use immutable page identity in LinksUpdate (needed for deletion)

https://gerrit.wikimedia.org/r/754047