How about on changing the error message to include the first arg:

Closing per my previous comment, and the related T392223#10753203 declining a different variant of the same bug.

Change #1113455 merged by jenkins-bot:

[mediawiki/core@master] RevisionStore: Query by page_id when available

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

The code making interwiki links may not know namespaces at other wikis so it may be unable to tell whether [[:en:Foo:Bar]] is a mainspace page called "Foo:Bar" or the page "Bar" in a namespace called "Foo". That means a general solution may have to allow any title with at most 255 bytes after a colon, at least if the part before the colon doesn't exceed the maximun possible size there. That means interwiki linking may generate url's like this with 255 a's and 259 total bytes in a mainspace pagename:
https://en.wikipedia.org/wiki/Foo:Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
So it would make a clickable wikilink at the source wiki but be an invalid too long page name at the target wiki. I don't think this is a serious concern. It would happen very rarely and not cause any problems I can think of. The current situation is worse when it's impossible to make interwiki wikilinks to some valid pages outside mainspace.

See w:User:PrimeHunter/Page name size in interwiki links for a nice explanation of this bug and see Template talk:Wikidata Infobox for the problems this bug is causing on Commons categories.

Because it has no code, due to T33951: Merge Interwiki extension into MediaWiki core

Preserving a few screenshots here for posterity:

Another example I have found is when you search Wikimedia Commons

In case another example would be useful/helpful for anything, searching for "thomas j watson wikiquote" currently results in Google directing me to a page on the English Wikiquote via the URL https://zh.wikipedia.org/wiki/q::en:Thomas_J._Watson

Change #1113455 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/core@master] [POC] RevisionStore: Query by page_id when available

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

In T380677#10461083, @kostajh wrote:

I'm trying to move https://www.mediawiki.org/wiki/Trust_and_Safety_Product/Team/Norms to https://www.mediawiki.org/wiki/Trust_and_Safety_Product/Team/Practices.

@SuzanneWood-WMDE and @seanleong-WMDE the operational issue should be fixed by the backport of the work-around I made, but I think the code in Wikibase doesn't work as intended. See my comments on the patch.

Mentioned in SAL (#wikimedia-operations) [2025-01-15T19:39:36Z] <brennen@deploy2002> Finished scap sync-world: Backport for [[gerrit:1111680|RevisionStore: No first revision of non-existing page (T380677)]] (duration: 17m 00s)

Mentioned in SAL (#wikimedia-operations) [2025-01-15T19:28:59Z] <brennen@deploy2002> bpirkle, brennen: Backport for [[gerrit:1111680|RevisionStore: No first revision of non-existing page (T380677)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-01-15T19:22:35Z] <brennen@deploy2002> Started scap sync-world: Backport for [[gerrit:1111680|RevisionStore: No first revision of non-existing page (T380677)]]

Change #1111680 merged by jenkins-bot:

[mediawiki/core@wmf/1.44.0-wmf.12] RevisionStore: No first revision of non-existing page

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

Change #1111680 had a related patch set uploaded (by BPirkle; author: Daniel Kinzler):

[mediawiki/core@wmf/1.44.0-wmf.12] RevisionStore: No first revision of non-existing page

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

Change #1111658 merged by jenkins-bot:

[mediawiki/core@master] RevisionStore: No first revision of non-existing page

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

Change #1111658 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] RvisionStore: No first revision of non-existing page

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

In T380677#10462762, @SuzanneWood-WMDE wrote:

@daniel happy for that change to be reverted if it's causing an issue, we'll also look into it

@daniel happy for that change to be reverted if it's causing an issue, we'll also look into it

Actually, the relevant code in Wikibase was merged just last week. Perhaps that's what introduced the bug? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1105355

Analysis:

• MovePage::moveToInternal calls PageUpdater::saveRevision() to create a new redirect page under the old title, after the original page has been moved.
• PageUpdater triggers the MultiContentSave hook and passes it a RenderedRevision object representing the new redirect page
• TemplateData's handler for this hook calls getRevisionParserOutput on the RenderedRevision. TemplateData's invokvement is probably not relevant, getRevisionParserOutput will get called sooner or later by something or other.
• RenderedRevision ends up calling ContentRenderer::getParserOutput which calls ContentHandler::getParserOutput
• ContentHandler triggers the ContentAlterParserOutput hook, passing it a Title object which it created by calling TitleFactory::newFromPageReference based on a PageReference representing the new redirect page. This PageReference was obtained from the RevisionRecord created by PageUpdater (see renderedRevision::getSlotParserOutputUncached). newFromPageReference () does not use a Title cache, but will inherit the page ID if the PageReference is a PageIdentity, which is the case here. Presumably, this ID is 0 at this point, sine the PageIdentifier object we are getting here was constructed before the page was created (to be confirmed).
• Wikibase's ParserOutputUpdateHookHandler calls ClientParserOutputDataUpdater which calls RevisionStore::getFirstRevision, passing the Title object created by ContentHandler.
• RevisionStore::getFirstRevision causes a database query for the oldest revision of the page. The query uses namespace and name, not the page ID! It seems likely that the page ID in the Title object at this point is either 0, instead of the newly created redirect (to be confirmed). However, the query should find the single newly created revision of the redirect page at this point (to be confirmed).
• RevisionStore finds revision rows and tries to instantiate a RevisionStoreRecord for them, passing in the Title object that was provided to the getFirstRevision () call. This fails, because the Title object has page ID 0.

I'll try to look into this today. If I can't find it in time, we'll have to revert https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1105447.

The trigger is different this time around, but it's another instance where we apparently try to instantiate a revision for a non-existing page. Probably something is getting out of whack due to the page move. It's triggered through Wikidata, so it doesn't show up in CI...

I'm trying to move a page on mediawiki.org and cannot do so because of this error. There are two errors:

Change #1110838 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.21.0-a11

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

Change #1110838 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.21.0-a11

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