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

[mediawiki/extensions/DiscussionTools@master] Temporarily disable failing test

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

Maybe https://gerrit.wikimedia.org/r/c/mediawiki/core/+/862391 ?

I can dig into it, but offhand, do you know if this is because of some missing call to a hook? There shouldn't have been any change in the section metadata itself -- just where it is used.

In T328072#8562594, @ssastry wrote:

Maybe https://gerrit.wikimedia.org/r/c/mediawiki/core/+/862391 ?

Yeah probably, our code here using getTOCHTML() might depend on the old behavior: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/3224d23c9528a753e4ec770531a3492e9421f89b/includes/CommentFormatter.php#68

I think as a quick fix, we could just remove that check and do the work unconditionally. And as a longer term solution, move some of the code that depends on user language to a post-cache transformation, like we've discussed with @cscott elsewhere.

And does this affect both vector and vector 2022, or just one of them? Basically the culprit patch just made vector behave more like vector 2022 (in terms of not prebaking the toc) so I'd be surprised if vector broke but vector 2022 didn't.

In T328072#8562653, @matmarex wrote:

In T328072#8562594, @ssastry wrote:

Maybe https://gerrit.wikimedia.org/r/c/mediawiki/core/+/862391 ?

Yeah probably, our code here using getTOCHTML() might depend on the old behavior: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/3224d23c9528a753e4ec770531a3492e9421f89b/includes/CommentFormatter.php#68

I think as a quick fix, we could just remove that check and do the work unconditionally. And as a longer term solution, move some of the code that depends on user language to a post-cache transformation, like we've discussed with @cscott elsewhere.

Oh yeah we talked about that elsewhere. There's a flag you could/should be using, not "is getTOCHTML empty".

In T328072#8562653, @matmarex wrote:

In T328072#8562594, @ssastry wrote:

Maybe https://gerrit.wikimedia.org/r/c/mediawiki/core/+/862391 ?

Yeah probably, our code here using getTOCHTML() might depend on the old behavior: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/3224d23c9528a753e4ec770531a3492e9421f89b/includes/CommentFormatter.php#68

I think as a quick fix, we could just remove that check and do the work unconditionally. And as a longer term solution, move some of the code that depends on user language to a post-cache transformation, like we've discussed with @cscott elsewhere.

Aha .. I should probably search for uses of getTOCHTML() in code search to see who else depends on that behavior.

From OutputPage.php:

		// T294950/T293513: ParserOutput::getTOCHTML() will be
		// replaced by ParserOutput::getTOCData(), and
		// ParserOutputFlags::SHOW_TOC is used to indicate whether the TOC
		// should be shown (or hidden) in the output.
		$this->mEnableTOC = $this->mEnableTOC ||
			$parserOutput->getOutputFlag( ParserOutputFlags::SHOW_TOC );

That's the flag code should be using, instead of looking for non-emptygetTOCHTML().

Change 884061 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Temporarily disable failing test

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

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

[mediawiki/extensions/DiscussionTools@master] Don't rely on ParserOutput::getTOCHTML() to determine if ToC is present

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

Change 884096 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Don't rely on ParserOutput::getTOCHTML() to determine if ToC is present

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