(it's almost all on mediawikiwiki)

(but this might be just because DiscussionTools is enabled there on almost all pages, due to wgExtraSignatureNamespaces including NS_MAIN, and not that interesting)

Why is DiscussionTools using StubMetadataCollector instead of a real ParserOutput? That seems to be the first question -- StubMetadataCollector should only be used in the 'standalone' mode of Parsoid, not the integrated mode.

But once you're using a "real" ParserOutput the warnings will disappear but the issue won't -- it seems to be that the limit report data is being overwritten at some point. Is that intentional? We're "losing" the old limit report data when we do this -- AFAIK the limit report really is meant to be written exactly once, in OutputPage.

I don't think DiscussionTools using StubMetadataCollector, we even typehint ParserOutput. I think something else somewhere is doing weird stuff to the ParserOutput we generate.

Is there anyway we can get a stack trace? It's coming from /rpc/RunSingleJob.php so likely Parsoid isn't being configured correctly in "headless" mode.

I suspect what's happening is that DiscussionTools is setting a limit report on a "real" ParserOutput (there are type hints in CommentFormatter::addDiscussionTools, so it has to be real at that point), but then someone is doing:

$stub = new StubMetadataCollector();
$stub->setLimitReportData(...something...);
// ...some time later...
$parserOutputFromDiscussionTools->collectMetadata($stub);

which then triggers the warning because the limit report data from the stub and from the 'real' ParserOutput can't be merged, and instead one of them is being dropped on the floor.

The collectMetadata method is only invoked twice, according to codesearch and in both cases the $stub of the example above would be the "thing passed in" to DataAccess::parseWikitext(... $stub ...) or DataAccess::preprocessWikitext(... $stub ...) and so would have to have the limit report already present in $stub before one of those methods was invoked. So who is creating a StubMetadataCollector and stuffing it with limit report data?

That's where the trail goes a bit cold and a stack trace would help. Most of the calls which construct a StubMetadataCollector are in testing or standalone/API-mode code and *shouldn't* be part of the stack trace here. (Of course, I can always be surprised.)

The likeliest culprits, tain entry points from src/Parsoid.php, which create a StubMetadataCollector are as follows:

• From Parsoid::wikitext2html(), only if the final $metadata parameter is null (it shouldn't be!), but it's calling parseWikitext on an empty stub metadata collector so it's hard to see how a preexisting limit report could be there, and AFAICT it doesn't leak/expose its stub metadatacollector outside the method.
• From Parsoid::wikitext2lint() -- always creates a new empty StubMetadataCollector but (a) it's empty, so it won't have a limit report in it, and (b) it's thrown away and doesn't escape the method.
• From Parsoid::dom2wikitext() - same as previous. Always creates a SMC but its empty and doesn't escape.
• From Parsoid::pb2pb() - again, always creates an empty SMC which doesn't escape
• From Parsoid::substTopLevelTemplates() - same: empty SMC which doesn't escape

So I've proved either that (a) this bug is impossible :) or (b) some of my logic here is wrong, or (c) codesearch isn't finding all the relevant cases (calls to collectMetadata or creation sites for StubMetadataCollector).