I had to purge both pages and then the links appear.

With our notifications to clients via job queue, purging is supposed to automatically happen.

The associated wikidata item was lasted edited on Jan 29

http://www.wikidata.org/w/index.php?title=Q2393031&action=history

so, there would have been no purge.

I don't know about retroactively going through and purging pages in the clients that are connected but connected before client deployments. (e.g. never got automatic purge.

If a purge fixes it and this is nothing that'll regularly happen I think we can close it.

We're getting more reports about this. Needs to be fixed.

• Bug 46055 has been marked as a duplicate of this bug. ***

currently a purge is necessary in some occasions to see the links, e.g.
http://en.wikipedia.org/wiki/Wickiana?action=purge

In the last couple of days, I have encountered some English articles that are linked to Wikidata, but the "Edit links" link is missing. For example, http://en.wikipedia.org/wiki/Dyrehavsbakken now had 9 interlanguage links, but there was no "Edit links" text. All local links were removed from the article a month ago.

Is this another bug or a new symptom of the same bug? Purging seems to help also in this case.

(In reply to comment #6)

In the last couple of days, I have encountered some English articles that are
linked to Wikidata, but the "Edit links" link is missing. For example,
http://en.wikipedia.org/wiki/Dyrehavsbakken now had 9 interlanguage links,
but
there was no "Edit links" text. All local links were removed from the
article a
month ago.

Is this another bug or a new symptom of the same bug? Purging seems to help
also in this case.

I think this is the same issue, yes.

I have not gotten any more reports about this so I assume it is fixed. Please reopen if not.

Verified in Wikidata demo sprint 22-5

Reproduced.

In T47839#1483410, @Bugreporter wrote:

Reproduced.

Can you please let us know how you reproduced this?

I couldn't find anything obvious regarding this in the logs, so I guess this is just something unrelated failing (like an exception happening during the page parse/ page props update/ …).

This occurs randomly. I don't find a pattern.

In T47839#1487241, @Bugreporter wrote:

This occurs randomly. I don't find a pattern.

I need more articles with this problem in order to debug this (preferably where the problem still exists). Can you give me some links, please?

Recently found one:
https://zh.wikipedia.org/wiki/%E9%80%B2%E5%8B%95
https://archive.is/w7qx9
https://www.wikidata.org/wiki/Q104225

Note https://en.wikipedia.org/wiki/Precession displays sitelinks correctly.

In T47839#1510893, @Bugreporter wrote:

Recently found one:
https://zh.wikipedia.org/wiki/%E9%80%B2%E5%8B%95
https://archive.is/w7qx9
https://www.wikidata.org/wiki/Q104225

Thank you... I poked at this today and searched through various logs but couldn't find anything relevant yet. If you have more examples, please post them here.

Another:
https://zh.wikipedia.org/wiki/Wikipedia:%E5%82%80%E5%84%A1%E8%B4%A6%E6%88%B7%E7%9A%84%E7%89%B9%E7%82%B9
https://archive.is/5HVg6
https://www.wikidata.org/wiki/Q11056804

Also:
https://en.wikipedia.org/wiki/White_Sea%E2%80%93Baltic_Canal
https://archive.is/0Zk3H
https://www.wikidata.org/wiki/Q461457

https://en.wikipedia.org/wiki/Wikipedia:Banning_policy
https://archive.is/3JruH
https://www.wikidata.org/wiki/Q6140266

https://en.wikiquote.org/wiki/Wikiquote:Requests_for_adminship
https://archive.is/wwjPF
https://www.wikidata.org/wiki/Q4048254

From Hebrew:
https://he.wikipedia.org/wiki/%D7%9E%D7%9C%D7%9B%D7%AA_%D7%94%D7%99%D7%95%D7%A4%D7%99
https://he.wikipedia.org/wiki/%D7%A8%D7%A6%D7%97_%D7%A7%D7%A0%D7%93%D7%99

Both have had sitelinks since 2012.

(Is it useful to anybody to post more examples of non-appearing links?)

https://de.wikipedia.org/wiki/Friends (https://www.wikidata.org/wiki/Q79784)

Thanks a lot for the examples. Please keep them coming. We're investigating.

Do you know if any of these pages had sitelinks shown before that then vanished? Or where they just not shown ever?

Wayback machine did retrieve those pages at some point where they had sitelinks. https://web.archive.org/web/20150403085642/https://he.wikipedia.org/wiki/%D7%A8%D7%A6%D7%97_%D7%A7%D7%A0%D7%93%D7%99 , https://web.archive.org/web/20150819004518/https://de.wikipedia.org/wiki/Friends

Thank you!
Katie just suggested adding more debug output around the langlinkhandler to get to the bottom of this.

Hint from dewp: It seems the link to Wikidata is also missing in these cases.

20:48:02 <Josve05a> Help, something is broken... https://de.wikipedia.org/wiki/Referendariat linked to https://en.wikipedia.org/wiki/Referendary, but not vice-versa. (Q465288) I removed the enwp link from the item (which added 1,038 byte(?)) and then re-added the link, and now it shows up on enwp again. What is broken here?
20:48:02 <Josve05a> https://www.wikidata.org/w/index.php?title=Q465288&action=history

And another one from Hebrew: https://he.wikipedia.org/wiki/%D7%90%D7%99%D7%99%D7%A8%D7%91%D7%95%D7%A1_A350

And yet another one: https://he.wikipedia.org/wiki/%D7%A0%D7%AA%D7%A0%D7%99%D7%94

This is an article about Netanya, one of the largest cities in Israel and one of the oldest in the Hebrew Wikipedia, which is a bit odd to me, because I was under the impression that this happens in new or obscure articles.

And another one: https://he.wikipedia.org/wiki/PSPACE

i am looking at a few pages that I found on English Wikipedia. These all are related topics, and would share some categories and templates, but not all pages in the category are affected.

they are missing sidebar links and the "Data item" link, as well as the wgWikibaseItemId js config variable.

the parser output (from cache) has entity usage of only X + T, but wbc_entity_usage table now has X + T + S for the page.

however, I also see:

Number of Wikibase entities loaded: 1

and the page is in Category:Coordinates on Wikidata

this indicates that the lookup of item id in the wb_items_per_site failed.

the relevant Wikidata item was edited on January 12, and the wikipedia page was lasted edited in September. The page table entry for the page has page_links_update on January 18. I first noticed the page later in the day on January 19, so not convinced me viewing the page triggered anything.

the item definitely has an entry for the page in the wb_items_per_site table, and also has X + T + S entries in the wbc_entiy_usage table, as well as an entry in the page_props table for "wikibase_item".

other things noticed:

• also notice that page_touched of the enwiki page is 18 seconds later than page_touched timestamp of the wikidata item.
• SiteLinkTable::getItemIdForLink uses a slave connection
• we wrap the SiteLinkLookup (db) in a CachingSiteLinkLookup which we probably still need to do, for other reasons
• at least for me, it appears that WikibaseLuaBindings hit the SiteLinkLookup (db lookup) first and then the LangLinkHandler uses SiteLinkLookup (cached) and then ClientParserOutputDataUpdater->updateItemIdProperty (cached). Seems odd if lua was able to get an id in order to do entity lookup and stuff (and cache it), and the subsequent stuff didn't get an id from the caching lookup.
• CachingSiteLinkLookup doesn't normalize the page title for the cache key. SiteLinkTable at least normalizes to convert underscores to spaces, since spaces is the form used there. Though, this might not be much or any problem in practice.
• We are inconsistent in the client in sometimes using $title->getPrefixedText to build a SiteLink (e.g. for lookup) and sometimes we use $title->getFullText() which may contain a fragment. In practice, might also not be a problem but can't be entirely sure.

possible ideas:

• could be just a database query error (e.g. timeout) when parsing the enwiki page
• could be a race condition that the site link was missing in the site link table (on the slave) at the moment lookup was done. (e.g. the site links get deleted and readded in process of parsing on wikidata? or were previously missing?) Below is what is done when saving site links:

public function saveLinksOfItem( Item $item ) {                                                 
    //First check whether there's anything to update                                            
    $newLinks = $item->getSiteLinkList()->toArray();                                            
    $oldLinks = $this->getSiteLinksForItem( $item->getId() );                                   
                                                                                                
    $linksToInsert = array_udiff( $newLinks, $oldLinks, array( $this, 'compareSiteLinks' ) );   
    $linksToDelete = array_udiff( $oldLinks, $newLinks, array( $this, 'compareSiteLinks' ) );   
                                                                                                
    if ( !$linksToInsert && !$linksToDelete ) {                                                 
        wfDebugLog( __CLASS__, __FUNCTION__ . ": links did not change, returning." );           
        return true;                                                                            
    }                                                                                           
                                                                                                
    $ok = true;                                                                                 
    $dbw = $this->getConnection( DB_MASTER );                                                   
                                                                                                
    //TODO: consider doing delete and insert in the same callback, so they share a transaction. 
                                                                                                
    if ( $ok && $linksToDelete ) {                                                              
        wfDebugLog( __CLASS__, __FUNCTION__ . ": " . count( $linksToDelete ) . " links to delete." );
        $ok = $dbw->deadlockLoop( array( $this, 'deleteLinksInternal' ), $item, $linksToDelete, $dbw );
    }                                                                                           
                                                                                                
    if ( $ok && $linksToInsert ) {                                                              
        wfDebugLog( __CLASS__, __FUNCTION__ . ": " . count( $linksToInsert ) . " links to insert." );
        $ok = $dbw->deadlockLoop( array( $this, 'insertLinksInternal' ), $item, $linksToInsert, $dbw );
    }                                                                                           
                                                                                                
    $this->releaseConnection( $dbw );                                                           
                                                                                                
    return $ok;                                                                                 
}

suggestions:

• maybe would help to instead use a master connection for site link lookup when parsing is happening.
• and the way sitelinks get updated seems suboptimal and could be improved. (at minimum, implement the // TODO suggested in the code)

maybe would help to instead use a master connection for site link lookup when parsing is happening.

Maybe something that used to use master and that the feature relied on was switched to slave? There were a lot of changes as part of T92357: Fix database master queries from HTTP GET/HEAD before active-active multi-dc.

The same problem was on page https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%81%D1%8F%D1%86 , fixed by null edit.

Another example: https://en.wikipedia.org/wiki/Bangor,_Gwynedd currently has no interwiki links or Wikidata link, last edited 3 days ago. The Wikidata item is https://www.wikidata.org/wiki/Q234178

the issues I mentioned regarding using a slave connection sometimes for the wb_items_per_site table might also be a problem for T44325