`Error: Class "Wikimedia\Parsoid\Wt2Html\XMLSerializer" not found` in PHPUnit tests
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	matmarex
	May 13 2025, 2:21 AM

Description

I am seeing this error in PHPUnit tests for DiscussionTools in multiple repositories:

Error: Class "Wikimedia\Parsoid\Wt2Html\XMLSerializer" not found

Examples:

Details

Related Changes in Gerrit:

Subject	Repo	Branch	Lines +/-
Bump wikimedia/parsoid to 0.22.0-a3	mediawiki/vendor	master	+7 K -3 K
Bump wikimedia/parsoid to 0.22.0-a3	mediawiki/vendor	master	+1 K -3 K
Fix XMLSerializer alias	mediawiki/services/parsoid	master	+13 -1
Update for Parsoid's rename of XMLSerializer to XHtmlSerializer	mediawiki/extensions/DiscussionTools	wmf/1.45.0-wmf.1	+5 -5
Update for Parsoid's rename of XMLSerializer to XHtmlSerializer	mediawiki/extensions/DiscussionTools	master	+5 -5

Customize query in gerrit

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Resolved	Release	jnuche	T392171 1.45.0-wmf.1 deployment blockers
		Resolved		matmarex	T393983 `Error: Class "Wikimedia\Parsoid\Wt2Html\XMLSerializer" not found` in PHPUnit tests

Event Timeline

matmarex created this task.May 13 2025, 2:21 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 13 2025, 2:21 AM

Caused by rGPAReeabc4a0c220: Rename XMLSerializer to XHtmlSerializer / rMW1be5b7585b97: Bump wikimedia/parsoid to 0.22.0-a2

Change #1144710 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

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

gerritbot added a project: Patch-For-Review.May 13 2025, 2:29 AM

There is a class_alias, but Composer doesn't support generating autoload data for class aliases, so the class is not loaded when the alias is used.

Change #1144710 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

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

matmarex closed this task as Resolved.May 13 2025, 2:53 AM

Change #1144715 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@wmf/1.45.0-wmf.1] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

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

Ugh, needs backporting.

matmarex added a parent task: T392171: 1.45.0-wmf.1 deployment blockers.May 13 2025, 2:55 AM

ReleaseTaggerBot added a project: MW-1.45-notes (1.45.0-wmf.2; 2025-05-20).May 13 2025, 3:00 AM

@matmarex I can't figure out if this is an actual blocker for 1.45.0-wmf.1. Is the fix required to ~~sync~~ deploy 1.45.0-wmf.1 to prod?

looking at logstash

Planning to backport this as soon as I've dealt with other deployment issues

Change #1144715 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@wmf/1.45.0-wmf.1] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

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

Mentioned in SAL (#wikimedia-operations) [2025-05-13T10:18:58Z] <jnuche@deploy1003> Started scap sync-world: Backport for [[gerrit:1144715|Update for Parsoid's rename of XMLSerializer to XHtmlSerializer (T393983)]]

Mentioned in SAL (#wikimedia-operations) [2025-05-13T10:26:19Z] <jnuche@deploy1003> matmarex, jnuche: Backport for [[gerrit:1144715|Update for Parsoid's rename of XMLSerializer to XHtmlSerializer (T393983)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Maintenance_bot removed a project: Patch-For-Review.May 13 2025, 10:30 AM

Mentioned in SAL (#wikimedia-operations) [2025-05-13T10:35:36Z] <jnuche@deploy1003> Finished scap sync-world: Backport for [[gerrit:1144715|Update for Parsoid's rename of XMLSerializer to XHtmlSerializer (T393983)]] (duration: 16m 38s)

Errors are no longer showing up in the logs

ReleaseTaggerBot edited projects, added MW-1.45-notes (1.45.0-wmf.1; 2025-05-13); removed MW-1.45-notes (1.45.0-wmf.2; 2025-05-20).May 13 2025, 11:00 AM

In T393983#10814639, @matmarex wrote:

There is a class_alias, but Composer doesn't support generating autoload data for class aliases, so the class is not loaded when the alias is used.

This answer doesn't quite make sense to me. We've done class_alias before in libraries, (eg 301b9150416ce6efa970caa61a149b77d7fd3378) and it didn't break production. The class_alias was on a PSR-4 path and should have been loaded as library code. Why didn't this work (and why did it work before?) and what would have been the "right" way to do this?

The missing piece of the puzzle is the fact that in the mediawiki/vendor repo, composer.json uses "classmap-authoritative": true:

This makes composer not use PSR-4 autoloading, but instead generate a map of all classes it knows about to the files that define them, and only load files from this list. In the vendor patch https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/1144664, if you look at the relevant files (I don't know which of the two is used in production), the entry for XMLSerializer is removed:

I am not sure why the previous times this did not break production. I see that in 301b91… (https://gerrit.wikimedia.org/r/c/mediawiki/libs/RemexHtml/+/731867), there was another entry in "autoload", and the class_alias calls were in the same files as the real classes; maybe one of those things, or both combined, made it work.

(sent too early) As for the "right" way to solve this, I think there isn't really one, but there are workarounds:

Just list all of the aliases explicitly in "autoload" in your composer.json. At that point it's probably easier to also keep the class_alias in the same file as the real class. This shouldn't be too bad if you don't have many of them.
Do this silly thing, which I just accidentally found by codesearching for "classmap-authoritative". I suppose this fake class definition makes Composer find it when generating its classmap. I wonder if it breaks Phan or IDEs…