Page MenuHomePhabricator

Parsoid behaves strangely on pages violating the Expensive Budget "expensive-parserfunction-category"
Open, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue:

What happens?:
Behaves strangely.

What should have happened instead?:
Pages violating the budget should have the cat "Kategori:Halaman dengan terlalu banyak panggilan fungsi pemilahan" https://www.wikidata.org/wiki/Q5324385 ("Category:Pages with too many expensive parser function calls") well visible at the bottom, irrespective whether the vioation originates from a module or from old-style parser functions. They should NOT land in cat "Kategori:Halaman dengan galat skrip" https://www.wikidata.org/wiki/Q7192108 ("Category:Pages with script errors") unless they suffer from some other script error.

Event Timeline

Taylor renamed this task from Parsoid behaves strangely on pages violating the Expensive Budget to Parsoid behaves strangely on pages violating the Expensive Budget "expensive-parserfunction-category".Nov 19 2025, 2:59 PM
Taylor updated the task description. (Show Details)

In your example, Kategori:Halaman dengan galat skrip / https://www.wikidata.org/wiki/Q7192108 / Category:Pages with script errors is never added by Parsoid unless the legacy parser also adds that category, so that seems to be a red herring. Parsoid is doing the exact same thing as the legacy parser.

Parsoid does seem to be undercounting the "expensive parserfunction" limit, causing it not to add Kategori:Halaman dengan terlalu banyak panggilan fungsi pemilahan" / https://www.wikidata.org/wiki/Q5324385 / Category:Pages with too many expensive parser function calls in some places where the legacy parser adds it. This is probably an instance of T310512: Parsoid and the legacy parser should emit exactly the same ParserOutput metadata, which is part of T393716: [EPIC] RefreshLinksJob should use Parsoid-generated metadata.

Note that Parsoid doesn't strictly guarantee where limits will be reached because fragments may be rendered independently (eg, in cases of selective update). This doesn't appear to be the issue here, but it is worth keeping in mind when comparing output of the legacy parser and Parsoid.