We noticed that there seem to be two clusters in the pattern of entity usage: one group has lower usage and the usages can be obviously connected to something in the page. The other cluster has extremely high (ie. 150-300) aspect count.

This task is about investigating the question and finding methods for debugging where the entity usage is coming from. We don't want to raise the limit just to catch pages which misuse entity aspects. These techniques worked out here will be helpful for helping us analyze the lower-count range to optimize the bundling limit.

Looking at the impact of raising the limit, there are two axes: "was there a diff to the page?" and "will there still be a specific entity usage triggered by the wikidata change?":

The "noise, but won't go away" cell is the focus of this task's investigation.

theory: unused usage

Current status: under investigation, supported by evidence so far.

In T441306 we discovered that various languages have a template like en:Authority control which looks for statements about hundreds of properties, each of which adds an entity usage regardless of the property having a value for the given entity. We learned that the usage was all coming from an authority control template and was looking for potential properties which didn't exist at the moment, but would be added to the page content once they did exist.

This seems like an appropriate use of entity usage. Once a statement is added for the property, the page is correctly refreshed and an RC is injected for a likely visible diff. For example, a new library ID is added and the link appears in the page's authority control navbar.

theory: unreasonable usage

Current status: no evidence in favor

This theory was based on there being some way to fool entity usage so that it looks like every property of an entity is used, when it is only iterated over.

If this theory were true, then it could be possible that raising the entity usage limit wouldn't improve the recent changes noise, but would have the negative impacts of increasing database usage and cluttering the page information view.

logging

We've added some logging which appears under "Wikibase" at the "info" level which is configured to not land in logstash, but instead lands on the mwlog server in the /srv/mw-log/Wikibase.log file. The lines look like this at the moment:

2026-10-12 03:26:01.292908 [2d433388-7b9a-4c72-8a53-82da47138cea] mw-web.eqiad.main-67c8cb7f6b-5fx42 frwiki 1.47.0-wmf.23 Wikibase INFO: Exceeded entity usage aspect bundling for aspect C {"count":184,"aspect":"C","entity_id":"Q587039","wiki":"frwiki"}

They are emitted whenever an entity usage aspect limit is exceeded.

debugging tools are lacking

We want to add the page_id to the log message to help debug problematic pages. As a stop-gap, we can look up the likely pages using the entity_id like so:

select
  count(1) as aspect_count,
  eu_page_id
from wbc_entity_usage
where
  eu_entity_id='Q60736973'
group by eu_page_id
order by count(1) desc;

But even once the page is identified, it's difficult to find which template or module is responsible for the excessive usage. Some things that don't work:

• Special:ExpandTemplates doesn't show entity usage. (Could add entity usage reporting here.)
• Previewing a page doesn't show changes in entity usage. See T441269: Page editing preview: wikibase entity usage is not dynamic in preview
• Copying a page into a user sandbox doesn't make the same Wikidata sitelink connection needed to trigger entity logic in many templates. (Could set the entity ID in page wikitext.)
• There is no way to see the full list of entity usage aspects, once the limit is exceeded. This data is present but is not displayed, even in the preview context where there is no benefit to bundling.

User-facing debugging tools would be especially nice to have.

We found one debugging technique which allows us to see entity usage before bundling happens:

$page = \MediaWiki\MediaWikiServices::getInstance()->getWikiPageFactory()->newFromID($pageid);
$parserOutput = $page->getParserOutput();
$euData = $parserOutput->getExtensionData('wikibase-entity-usage');
ksort($euData);

This could be useful to package as a maintenance script.

Patch for review: https://gerrit.wikimedia.org/r/c/1357254

commonswiki

Wikidata RC injection is disabled on Commons, and the entity usage patterns there are unlike other wikis. We should probably filter this wiki out of the analysis—or even stop creating entity usage there.

What we see is that the label and description are often repeated for every available language, which creates a large number of usage rows per page. This also complicates the potential (but disabled) recent change notifications since they would trigger if any language changed. In future work, it might be worthwhile to reconsider the way the pages are designed and to transclude language-based subpages like "/wiki/File:ABC.jpg/en" based on the user's interface language.

This might still be problematic when you look at the outcome on other multilingual wikis such as metawiki, where the same change can also affect all languages of subpage:

• We should document why it did not work, if the research says so (revisit this after the research)