Page MenuHomePhabricator

WAN Cache of preprocess-hash is not respecting $wgCacheEpoch or changes to availability of extension tags
Open, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Create a template longer than $wgPreprocessorCacheThreshold with a non-existing extension tag, e.g. <img src="[image URL]" />
  • Create a page with direct usage of that tag, vs using the template
  • Install an extension that implements that tag, e.g. https://github.com/lihaohong6/ImgTag
  • Check the parsed page
  • Restart the PHP service if using APCu for WAN Cache (which clears the preprocess-hash cache), or clear the cache manually if using other object cache.
  • Check the parsed page again

What happens?:

For the first time, the direct usage of the tag rendered correctly, but the one from the template is still broken.

After clearing the preprocess-hash cache, the one from the template also rendered correctly.

This may not be an issue under normal circumstances, as usually non-existent extension tags won't be used before the extension is installed. But it can break the wiki when upgrading from 1.39 to 1.43, since the support of parsing the img tag as a native HTML tag is removed from the parser between these two LTS versions. With the preprocess-hash cache from 1.39, it's not parsed as an extension tag, and it's difficult for server admin to clear the cache if not using APCu as the WAN Cache.

What should have happened instead?:

WAN Cache of preprocess-hash respecting $wgCacheEpoch, or the list of available extension tags, etc.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Event Timeline

Func renamed this task from WAN Cache of preprocess-hash is not respecting $wgCacheEpoch to WAN Cache of preprocess-hash is not respecting $wgCacheEpoch or changes to availability of extension tags.Dec 2 2025, 4:41 AM

Change #1213625 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@master] Parser: Vary the preprocess-hash by the list of available extension tags

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

Change #1213625 merged by jenkins-bot:

[mediawiki/core@master] Parser: Vary the preprocess-hash cache by extension tags available

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

Change #1216697 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@REL1_45] Parser: Vary the preprocess-hash cache by extension tags available

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

Change #1216698 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@REL1_44] Parser: Vary the preprocess-hash cache by extension tags available

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

Change #1216699 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@REL1_43] Parser: Vary the preprocess-hash cache by extension tags available

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

Just bumping the cache version would be sufficient for the 1.39 to 1.43 upgrade, wouldn't it?

With the transition to Parsoid, there are already Parsoid-only extensions (WikiFunctions) and so I'm a little bit reluctant to tie the cache key tightly to the legacy parser's list of installed tags. I'm also nervous about the fact that this cache key doesn't respect the frame volatile flag.

I think I would have preferred that the backported patch just bump the cache version, and then we can iterate on this more-complete patch for 1.46, possibly with another bump in the cache version.

Just bumping the cache version would be sufficient for the 1.39 to 1.43 upgrade, wouldn't it?

Only if the server admin is fully aware of the removal of the native HTML img tag and the procedure to install the alternative extension before upgrading. There is too much room for mistakes, and it's still very hard to debug once that happens.

With the transition to Parsoid, there are already Parsoid-only extensions (WikiFunctions) and so I'm a little bit reluctant to tie the cache key tightly to the legacy parser's list of installed tags. I'm also nervous about the fact that this cache key doesn't respect the frame volatile flag.

Isn't this cache only for the legacy parser? I didn't see Parsoid reference this cache key from code search.

I think I would have preferred that the backported patch just bump the cache version, and then we can iterate on this more-complete patch for 1.46, possibly with another bump in the cache version.

I would rather go with $wgCacheEpoch if we must not use the legacy parser's list of installed tags.

Change #1216698 merged by jenkins-bot:

[mediawiki/core@REL1_44] Parser: Vary the preprocess-hash cache by extension tags available

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

Change #1216699 merged by jenkins-bot:

[mediawiki/core@REL1_43] Parser: Vary the preprocess-hash cache by extension tags available

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

Change #1216697 merged by jenkins-bot:

[mediawiki/core@REL1_45] Parser: Vary the preprocess-hash cache by extension tags available

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