This affects other (but not all) discussion pages on ruwiktionary and other projects as well. Could it be related to T419262?
https://de.wiktionary.org/wiki/Benutzer_Diskussion:Alexander_Gamauf?useparsoid=0 shows the reply tool while https://de.wiktionary.org/wiki/Benutzer_Diskussion:Alexander_Gamauf?useparsoid=1 doesn't, because all the signatures aren't properly recognized.

The page mentioned in the page description also works without Parsoid: https://ru.wiktionary.org/w/index.php?title=Викисловарь:Технические_вопросы&useparsoid=0

Probably not related to T419262, since that's only triggered during language converter testing AFAIK. More likely related to T372592 / Enables legacy processing in ParserOutputPostCacheTransform when cached (1225002) · Gerrit Code Review if this began very recently.

Adding this as a train blocker as I expect this will affect all wikis with discussion tools once wmf.19 rolls out.

Seems related to wmf.19. Masked because requires a new parse (or action=purge) to regenerate the page to show the bug. At present I can reproduce the missing reply links on:

• https://en.wikivoyage.org/w/index.php?title=Talk:Main_Page&useparsoid=1 (group 1)
• ruwiktionary (group 1)

And these don't seem affected yet:

• ruwiki (group 2)
• ruwiktionary 1 (group 1)
• ruwiktionary 2 (group 1)

So it's not *every* discussion page, and it seems confined to useparsoid=1. Investigating...

What seems to at issue is this code from ParserHooks.php: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1225002/8/includes/Hooks/ParserHooks.php

		// as per Id73a1b5751cfc055e84188bcb19583c72b84032f, this is always set when transforming HTML
		// in DiscussionTools, so it's a reasonable way to not execute it twice for legacy content coming
		// from the ParserCache
		if ( $parserOutput->getExtensionData( 'DiscussionTools-isEmptyTalkPage' ) !== null ) {
			return;
		}

This test seems to work fine for the legacy parser, but on parsoid-rendered pages "of sufficient complexity" (short discussion pages don't seem to trigger this) that extension data property is being set which is causing Parsoid to skip DT rendering of the content.

I've created a revert at Revert "Enables legacy processing in ParserOutputPostCacheTransform when cached" (1251121) · Gerrit Code Review to unblock the train, but let me see if I can narrow down a smaller test case to allow us to reproduce this before we deploy the revert.

Change #1251123 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/extensions/DiscussionTools@master] Ensure that we always run ParserHooks::transformHtml() when using Parsoid

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

https://en.wikivoyage.org/wiki/User_talk:Cscott/T419830 is a pretty small reproducer. It seems like something inside the {{ArchivedDiscussions}} template is causing the bug.

@DLynch says:

If isEmptyTalkPage is getting set we do think it should be a talk page at the Title level, at least.
So it means we’re not finding any comments on the page.
I guess this could be the reemergence of the “an interface notice was parsed, and we thought it was the main content” bug.

I strongly suspect there's a subrender going on somewhere here: the parser is being invoked recursively and you're not finding comments on the small piece you're looking at in the recursion.

I manually expanded the {{ArchivedDiscussions}} template and it turns out that it is TemplateStyles which triggers the bug:

<templatestyles src="ArchivedDiscussion/styles.css" />

== Help needed with tweaking visual balance of the main page ==

If someone with the correct rights (presumably bureaucrats?) and technical know-how can help me out with this, then that'd be much appreciated! <br/> <span style="font-family:atkinson hyperlegible">― '''[[User:Wauteurz|Wauteurz]]''' <small>([[User talk:Wauteurz|talk]])</small></span> 15:00, 23 March 2025 (UTC)

is a near-minimal reproducer.

The backtrace on the recursive invocation caused by <templatestyles> is at F72821664.

Note that ::addDiscussionToolsInternal() is surrounded by a try { } catch (\Throwable) { } so it's a little tricky to generate that backtrace. :)

Parsoid invokes Parser::parseExtensionTagAsTopLevelDoc() to expand the <templatestyles> which then invokes ::onParserAfterTidy() on the output of <templatestyles> which then runs the onParserAfterTidy hook in DT which invokes ::transformHtml(), all on the output of the <templatestyles> extension.

Change #1251133 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/extensions/DiscussionTools@master] Don't invoke ParserAfterTidy hook from Parsoid extension handling

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

From this testing and diagnosis I'm pretty confident in Ensure that we always run ParserHooks::transformHtml() when using Parsoid (1251123) as a short term fix/backport.

Don't invoke ParserAfterTidy hook from Parsoid extension handling (1251133) · Gerrit Code Review is a root cause fix -- the ParserAfterTidy hook should just go away once we fully transition to the new postprocessor -- but although that works in local testing I think there's some room for discussion on that one about how best to detect the "Parsoid invoking AfterTidy" case. Some options there:

• should we use ParserOptions::getUseParsoid() (the present patch)
• should we use the presence of a page bundle (is it guaranteed present for recursive invocations)
• should we use the presence of a postprocessing cache (ie signal upfront that we're doing postprocessing) we're looking at $wgUsePostprocCacheLegacy but we could be looking at something in Article (::getUseLegacyPostprocCache() but that's misnamed for parsoid) to determine that we're using a postprocessing cache.
• should we pass an explicit flag from Parsoid to recursive invocations of the legacy parser
• should we reconsider Parsoid DataAccess: Stop processing extensions as top-level docs (977312) or T352451: Parsoid runs ParserAfterTidy & ParserAfterParse hooks multiple times, causing problems for DiscussionTools

etc

So we'll let that root cause fix wait for a discussion which backporting 1251123 to unblock the train and fix production.

Change #1251139 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/extensions/DiscussionTools@wmf/1.46.0-wmf.19] Ensure that we always run ParserHooks::transformHtml() when using Parsoid

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

Change #1251123 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Ensure that we always run ParserHooks::transformHtml() when using Parsoid

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

Change #1251139 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@wmf/1.46.0-wmf.19] Ensure that we always run ParserHooks::transformHtml() when using Parsoid

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

Mentioned in SAL (#wikimedia-operations) [2026-03-12T18:08:28Z] <brennen@deploy2002> Started scap sync-world: Backport for [[gerrit:1251139|Ensure that we always run ParserHooks::transformHtml() when using Parsoid (T419830)]]

Mentioned in SAL (#wikimedia-operations) [2026-03-12T18:10:36Z] <brennen@deploy2002> cscott, brennen: Backport for [[gerrit:1251139|Ensure that we always run ParserHooks::transformHtml() when using Parsoid (T419830)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Thanks, @brennen. I can help test.

Mentioned in SAL (#wikimedia-operations) [2026-03-12T18:23:14Z] <brennen@deploy2002> Finished scap sync-world: Backport for [[gerrit:1251139|Ensure that we always run ParserHooks::transformHtml() when using Parsoid (T419830)]] (duration: 14m 46s)

In T419830#11703255, @cscott wrote:

The backtrace on the recursive invocation caused by <templatestyles> is at {F72821664}

The file is not visible, could you please attach it to the task? Thanks in advance!

Related to T419908: DiscussionTools duplicates the meta-data sub-header content when Previewing.

Change #1251133 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Don't invoke ParserAfterTidy hook from Parsoid extension handling

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