See https://gerrit.wikimedia.org/r/1068812 and https://gerrit.wikimedia.org/r/1068125 as a pointer for the place in the code which needs to be tweaked.

I guess that if we want to pursue fixing this, we might want to generalize something. As-is we have to specify individual parameters sent to ApiVisualEditorEdit, which are then passed through into action=parse, but it'd be fairly easy to just bundle up "unknown view parameters" and hand them all over...

If I recall, ApiVisualEditorEdit producing the new HTML (and associated metadata) has been an ongoing source of maintenance woes. It's even worse when you need to interact with extensions that want to modify it (FlaggedRevs has been a big one, but I also vaguely recall interop issues with DiscussionTools and MobileFrontend).

Any chance you might want to drop that part completely, and make VE fetch the new HTML using an action=parse request instead? I think it has originally been implemented all in one requests to avoid extra roundtrips, and because chaining multiple promises in JavaScript was difficult, but today the roundtrip matters less thanks to HTTP/2 and promises are no longer hard to work with.

Might be worth doing some testing, at least, to see what the performance impact is. We can already request that ApiVisualEditorEdit not return the new HTML (nocontent), so it'd be pretty trivial to send that in and then manually call parse.

That said, it'd still be a kinda identical set of problems -- we'd just be calling parse from the frontend rather than from the backend. All it'd get us is not needing to pass some things through ApiVisualEditorEdit; we'd still need to know to pass whatever-it-is to the parse call wherever it's happening.