Here's what I get with ?debug=1 and commenting out //.catch( that.handleError ); (was attempting to get a better stack trace, but still can't make much sense of this.

Adding @Chlod, who has worked on this part of delete.js before.

Step debugging reveals the line triggering the problem in PageTriage is:
https://gerrit.wikimedia.org/g/mediawiki/extensions/PageTriage/+/15da0e014bfaa505f4856346d61cda709bbc8b94/modules/ext.pageTriage.views.toolbar/delete.js#995

const topicTitle = contentLanguageMessage( topicTitleKey, pageName ).text();

I found this.map.exists. It's in Message.prototype(). Possible upstream bug?
https://gerrit.wikimedia.org/g/mediawiki/core/+/0d45f127f5e448b1105a8efbeb7184c23ff86ff7/resources/src/mediawiki.base/mediawiki.base.js#200

/**
 * Check if a message exists. Equivalent to {@link mw.Map#exists}.
 *
 * @memberof mw.Message
 * @return {boolean}
 */
exists: function () {
	return this.map.exists( this.key );
}

@Novem_Linguae It seems to have been broken by this commit. .exists doesn't exist for native JS Maps, but only mw.Map maps. Should be a simple replacement; I'll have a patch filed in a sec.

Oh, there's actually two solutions to this. One is to revert the aforementioned commit and restore the use of a mw.Map, or change core to ensure that it works with normal JS maps. That itself has two solutions: change the behavior of mw.Message.exists depending on the map used using instanceof, or switch that function to use .has and then add a .has alias on mw.Map which just calls .exists. The latter seems best here, since it means other extensions/tools/etc. would be able to use native JS maps and not fall into the same issue.

In T353571#9410861, @Chlod wrote:

Oh, there's actually two solutions to this. One is to revert the aforementioned commit and restore the use of a mw.Map, or change core to ensure that it works with normal JS maps. That itself has two solutions: change the behavior of mw.Message.exists depending on the map used using instanceof, or switch that function to use .has and then add a .has alias on mw.Map which just calls .exists. The latter seems best here, since it means other extensions/tools/etc. would be able to use native JS maps and not fall into the same issue.

Definitely .has, we shouldn't revert that commit.

I don't think we should care about compatibility with mw.Map in this case, mw.Map is being all but deprecated, adding a new function at this point doesn't make sense.

That may be true, but if I'm not going to use an instanceof and will change mw.Message to call .has, it would break every other thing using an mw.Map since it doesn't have a .has function, and we can't search for all use cases doing this to be able to safely switch to using just .has (CodeSearch doesn't find uses in gadgets, userscripts, extensions not hosted on Gerrit, etc.). It's better to add that alias for now to avoid breaking things and for backwards compatibility, and then remove mw.Map as a whole later on, when we've announced its deprecation and we're ready to remove it (tracked in T353076).

As of now, this seems to need a high-priority fix, as it breaks part of the CSD tagging process. Since the deprecation of mw.Map is still stuck in code review (and there's no timeline for its completion, nor does it seem to remove mw.Map entirely), this compromise seems like the best solution right now. I'll file a patch, but given that it's a weekend, it'll probably not be merged (and this bug won't be solved) until next week.

cc @Jdforrester-WMF; you might have a better opinion on this. If there's a better solution, I'll be happy to abandon a patch containing the solution mentioned above.

Oh I now the issue (I was under the impression that the .exists() was in the PageTriage land). It seems the easiest scenario for now is to revert the PageTriage patch for now until the mw.Map patch is merged. I can try and see if we can deploy it on the Monday morning timeslot.

Also selenium tests need to be priority for PageTriage going forward :(

Yeah, revert seems easiest. In light of the above, it's probably better to switch from mw.Map to Map when the question of how .exists/.has will be handled is answered, or when we know that core can definitively support native JS maps. Discussing the changes to be made on core seems like it'll take time.

Change 983528 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/PageTriage@master] Revert "util.main: Don't use mw.Map(), use a native Map() instead"

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

Change 983528 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Revert "util.main: Don't use mw.Map(), use a native Map() instead"

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

Change 983529 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/PageTriage@wmf/1.42.0-wmf.9] Revert "util.main: Don't use mw.Map(), use a native Map() instead"

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

Change 983529 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@wmf/1.42.0-wmf.9] Revert "util.main: Don't use mw.Map(), use a native Map() instead"

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

Mentioned in SAL (#wikimedia-operations) [2023-12-18T14:53:54Z] <urbanecm@deploy2002> Started scap: Backport for [[gerrit:983229|Configure and enable StatsLib for production (T343024)]], [[gerrit:983529|Revert "util.main: Don't use mw.Map(), use a native Map() instead" (T353571 T353076)]]

Mentioned in SAL (#wikimedia-operations) [2023-12-18T14:55:12Z] <urbanecm@deploy2002> cwhite and urbanecm and chlod: Backport for [[gerrit:983229|Configure and enable StatsLib for production (T343024)]], [[gerrit:983529|Revert "util.main: Don't use mw.Map(), use a native Map() instead" (T353571 T353076)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2023-12-18T15:04:19Z] <urbanecm@deploy2002> Finished scap: Backport for [[gerrit:983229|Configure and enable StatsLib for production (T343024)]], [[gerrit:983529|Revert "util.main: Don't use mw.Map(), use a native Map() instead" (T353571 T353076)]] (duration: 10m 20s)