Page MenuHomePhabricator

Missing labels on items (statements show item IDs instead of labels even though labels are defined)
Closed, ResolvedPublic8 Estimated Story Points


Some people are seeing item IDs instead of labels in statements (reported e. g. by @Magnus on Twitter and by @Nikki on IRC). This can currently be seen on Q24306770: the “main subject”, “published in” and “cites” values all display as item IDs, even though the items have English labels. Purging or editing the page has consistently fixed the problem so far, but of course only for individual affected pages.

Screenshot_2018-09-26 The novel estrogen-induced gene EIG121 regulates autophagy and promotes cell survival under stress.png (569×796 px, 24 KB)

@WMDE-leszek Could this be related to Wikidata-Ugly-Cat-Trailblaze (wb_terms trail blazing)? But I thought those changes were only deployed for a certain range of item IDs (T201831 – I don’t know if the value item ID or the page item ID is the relevant one), and the item IDs in Q24306770 all look like they should be outside the affected range.

Event Timeline

Could this be related to Wikidata-Ugly-Cat-Trailblaze (wb_terms trail blazing)

hmm, looking at the screenshot I'd tend to say "probably not", as the new formatter code is only use to format items Q1..Q100,000 in statements, and all Q-IDs in the picture are way beyond that range.
This does not mean that I close the possibility that work was somehow resulting in this problem, although that would be some unexpected side effect if it was related.

I regularly use the WEF Framework gadget, and over the last several days I am seeing this problem come and go.

There is a variation in the problems the range I am seeing is

  • no labels render at all through the gadget; (least often)
  • the labels in the form render, though labels in the dropdowns do not, the selections do not
  • the labels in the form and the dropdowns render , though the typeahead choices do not render (when playing up this is the most regular misbehaviour)
  • behaving normally

The problem can last for half a day or so with the variations, though again one misbehaviour predominates.

Does this occur for multiple people on single items?

Could you write some steps to try to reproduce? Or example links if it is happening right now?

To reproduce, I just click "random item" a few times, one will show up very quickly.

Example right now: The "published in" statement on . The statement target (Q27713832) has an en label.

To reproduce, I just click "random item" a few times, one will show up very quickly.

Example right now: The "published in" statement on . The statement target (Q27713832) has an en label.

Managed to reproduce and also found

Addshore set the point value for this task to 8.Oct 9 2018, 1:29 PM

Could also be related to T204791
It is probably something bad ending up in the parser cache for some reason.

@Addshore As I mentioned above, whilst I a having some issues with WD directly, I am having greater issues with WEF framework tool's lookups. As I create items and do the lookup for matching terms it is finding items successfully, though the rendering of the name into the visible for selection is regularly not occurring. If it was anything but the lookup I could say I had caching issues, however, the lookup will be fresh name every time.

So the main thing that we are seeing here (badly cached pages in the parser cache) seems like it could have been some temporary issue (although I have no idea what the issue was).
All of the pages I linked to in T205556#4654519 are now fine after re parses, and hitting Special:Random repeatedly, I can no longer find any pages with issues :/

If anyone does spot another page where this is happening please write a comment on this ticket including the following:

  1. Link to the page
  2. Parser cache key & date of the page.

The parser cache key nd date of the page can be found in the HTML source of the page and will look like this (you can just search for pcache):

<!-- Saved in parser cache with key wikidatawiki:pcache:idhash:44779291-0!wb=3 and timestamp 20181011141845 and revision id 598318328
Addshore lowered the priority of this task from High to Medium.Oct 18 2018, 8:29 AM

Changing from High to Normal as this seems to have stopped.
Will continue to monitor on the campsite board for a few more days.

So, I'm going to mark this as resolved as this issue has gone away.