@Manuel Do you know if this is the same issue as T233520 which is being worked on atm?

At the first glance, I did not think so, but reading the comments in T297238 it actually might be. @Michael could you please help us clarify?

Purging some of the pages?

Purging the pages in mkwiki should always fix these things.

There was a problem with sitelinks having been newly added to Wikidata, but this should have been fixed since about a week ago.

Is it known whether new instances of this issue occurred _this week_? Or is it just holdovers from before? In the latter case, purging those pages on mkwiki should be good enough to fix it.

Based on our tracking: Langlinks should appear properly for sitelinks added after Thursday last week: https://grafana.wikimedia.org/d/hGFN2TH7z/edit-dispatching-via-jobs?viewPanel=24&orgId=1&from=1642464000000&to=now

Though it might take a while for them to actually appear on the mkwiki page. If I remember correctly, then the job that purges the page isn't high priority (as opposed to the job that injects the change into the recent changes and watchlists)

In T299828#7653095, @Michael wrote:

Purging some of the pages?

Purging the pages in mkwiki should always fix these things.

“These”? Meaning “interwiki links are correctly displayed in the sidebar, but are not present in the sitelinks table and the API does not return them”? OK, so I went ahead and purged the mkwiki category page. It dit not fix the problem.

In T299828#7653178, @Michael wrote:

Though it might take a while for them to actually appear on the mkwiki page.

Well, as the links have been visible on the mkwiki page from the very beginning, it’s probably not very surprising the interwiki links do still appear on the category page, but the API request still does not return them.

Ah, then I misunderstood the issue and confused it with a similar sounding one. I'm sorry, I will take another look at what is going on here.

So after looking into it some more and some pointers from a colleague:

Originally, this seems to indeed having been caused by sometimes not scheduling the correct job if a new sitelink was added. That was fixed, and that fix is deployed since about January 20th. So for sitelinks being added after that, this should not be happening anymore.

To fix pages from before that, a purge is indeed not enough. It needs a purge with forced links update. This can be done via the api. A null-edit probably also works.

While this should work automatically for future sitelinks being added to Wikidata, the job which triggers that refresh of links has currently a backlog of over 3 days.

Thank you for your thorough investigation, @Michael!

@Mormegil, does this help?