Page MenuHomeMiraheze

500 error when attempting to create certain pages
Closed, ResolvedPublic

Description

Since yesterday morning, it seems that pages in the Entry namespace (for my Tovasala Dictionary) beginning with S--uppercase or lowercase--cannot be created. (Wonder if other namespaces are affected as well?) This was first observed while trying to create one for saumdostar (to add up/sum up/calculate/enumerate/compute) through Page Forms, and now the same thing is happening (off-form) for SudGalige (the Republic of Ireland).

This contributor uses Chrome on a Galaxy Tab A to edit Miraheze. In both cases, Chrome outputs this browser-specific message:

This page isn't working

constantnoble.miraheze.org is currently unable to handle this request.

HTTP ERROR 500

I myself am not really sure what the problem is, but I reckon it might have begun when I introduced "Form:Entry/RFM" (imported from Referata RFM) yesterday, after a month of waiting out another outage from my former host.

On a related note: The Form namespace isn't configured to recognise subpages at the moment, at least on my wiki, and I don't want anything to break through ManageWiki or otherwise. See this November 2020 discussion with developer Yaron Koren, as well as this local namespace API overview.

Event Timeline

Routhwick triaged this task as Unbreak Now! priority.Mar 2 2022, 15:45
Routhwick created this task.
RhinosF1 lowered the priority of this task from Unbreak Now! to High.Mar 2 2022, 16:16

Thanks for the report. We can check the logs for you.

Can you share an example?

For SudGalige, the normal wiki code I'm trying to process looks like:

{{Definition/Sandbox|rfm|CL1=place
|IPA=sud./ɡæ.lɪɡ|SYL=sud, ga, lige
|Origin=Compound|M2=sud:e/Galig:e
|S=Republic of Ireland
|CRD=NoardGalige:Northern Ireland
|K=Countries, Ireland|WL=Europe
|Added on={{subst:#time:Y-m-d, H:i}}}}

...Never mind, it finally got through! Now, as for saumdostar...

Add another victim to this list: "Entry:soiye", which refuses to save traditionally or form-assisted. Code below in case @RhinosF1 wants to take a crack at it:

{{Definition/Sandbox|rfm|CL1=nns|IPA=s/ɔɪ
|Origin=From|Lang.=English|Etymon(s)=soy|Etymon notes={{wikt|soy#Etymology|via Dutch ''soja'', from Satsuma Japanese ''醤油'' [''そい''<nowiki>,</nowiki> ''soi''] [''soj''] (a variant of standard Japanese ''醤油'' [''しょうゆ''<nowiki>,</nowiki> ''shōyu'']}}
|S={{Entry|soybean}} plant|SB=Y
|USG=For the bean, see ''{{Entry|soiyène}}''; for the sauce, ''{{Entry|soiysauze}}''; for the milk product, ''{{Entry|soingorde}}''.
|HPE=fazole|K=Legumes
|Added on={{subst:#time:Y-m-d, H:i}}}}

(Already processed, though a 500 error came up on my end when I myself tried minutes ago.)

Reception123 lowered the priority of this task from High to Normal.Mar 3 2022, 07:13

(Seems to be quite specific to creating PageForms-related content, other similar errors are classed as 'normal')

Having trouble with "Entry:sauze" as well. Although it went through the first time, it was "double-saved" and I deleted this old version per my penchant for clean edit histories. Recreating it is taking no effect either. Code:

{{Definition/Sandbox|rfm|CL1=nns|IPA=s/ɔz
|Origin=From|Lang.=English/Old French|Etymon(s)=sauce|Etymon notes=descended from Latin ''{{wikt|salsus}}'' [salted]|Source(s)=wikt:sauce|Addtl. notes=Doublet of English/Spanish ''{{Entry|salsa}}''
|S=sauce
|HPE=bauyinzeande|K=Cuisine
|Added on={{subst:#time:Y-m-d, H:i}}}}

(Again, rectified after this posting. Stay tuned as I go through some more in the "S" list.)

As I ping back, Page Forms is still refusing titles beginning with S, thus forcing me to create their pages the regular way firsthand. Right now, another title--beginning with a T--is not going through; same 500 as described above, plus a 502 on Miraheze's end. Perhaps this may be a good time for the Miraheze team to test out this form link for tulajonar (attribute/ascribe to an author)? (Said content has already been deleted twice because it didn't show up as a new page on RecentChanges.)

Ignore the deletion below; that was a double-posted duplicate. (Just my luck Chrome-wise...)

This comment was removed by Routhwick.
Routhwick added subscribers: Unknown Object (User), Dmehus, MacFan4000.Mar 7 2022, 14:32

Another two days have passed, and the Page Form holdups more or less persist. This time, the affectees are a series of terms beginning with "T"; same 500 as before. All but one of them were successfully processed outside PF for what it's worth:

  • tuime (pair of twins)
  • tuisil (from a pair of twins) (502 showed up in the first attempt, and no appearance in RecentChanges; the second try miraculously went through with PF.)
  • tolube (issue--of a periodical, newspaper, newsletter, &c.)
  • teisende (version/edition)

And while we're at it, any RFM term beginning with an S has been as good as created traditionally, while I await further details or a diagnosis from the Miraheze team. (See Saturday's dispatch above for the form-testing link.) I know @Universal_Omega's practically on leave at this point, but perhaps he could come take a look and investigate? Or perhaps @RhinosF1 can take a crack at it again? Maybe @Dmehus or @Agent_Isai or @MacFan4000 might be of some assistance... <shrugs/> I don't know. (At this point, I've run out of suitable names to ping to.)

Please keep in mind: As far as I can ascertain, this holdup affects only the Entry namespace on my creative-venture wiki, and only a certain subset of first letters (S and T) vs. the "Entry/EN" form. (Which should be a subpage of the "Entry" landing area, a reminder to use the language-specific versions instead when creating new definitions--but PF, as mentioned before, currently lacks that configuration on my wiki.)

I might reach out to Mr. Koren at MW.org at some point--in case we hit an upstream bug or something.

For now, staff, have a pleasant morning/afternoon (depending on which side of the Atlantic you're based on). Benparl, tauwtés!

@Routhwick Thanks for the ping, and for reporting this issue since some extensions do use special pages to create pages, so it's a problem, which I'm not sure is either an upstream issue or a configuration issue. In any case, it doesn't seem to be a permissions-related issue (i.e.. managewiki-restricted), so I'm unlikely to be of use here. @Agent_Isai appreciates the ping also, but only to the extent of communications management.

Please feel free to keep my updated.

Unknown Object (User) unsubscribed.Mar 8 2022, 06:19

To @Agent_Isai and @RhinosF1: Some time ago, another "T" entry--toambar, to fall--struggled even through normal editing a while (complete with 500s and 502s). Otherwise, see Monday's dispatch for the rest of the current story.

Another week has passed, and the 500 problem hasn't subsided. This time, yet another "T" entry--tuarène, fog/mist/haze--ran into the same problems as toambar minutes before press time, and has not shown up correctly (i.e. announced in recent changes) as I hit "Submit". To top it off, I was about to give the Referata RFM imports a break with this one. Code:

{{Definition/Sandbox|rfm|CL1=nns|IPA=t/wa./ɹɛn|SYL=tua, rene
|Origin=From|Lang.=Maori|Etymon(s)=tuarehu|Etymon notes=mist|Source(s)=wikt:mist#Translations
|S-1=fog; mist; haze|S-2=blur
|USG=For the condition, see ''{{Entry|tuareneuzi}}''.
|K=Substances, Weather, Natural world|WL=Weather
|Added on={{subst:#time:Y-m-d, H:i}}}}

Otherwise, see the previous reports for the rest of the story. Remember, this only affects a certain subset of titles in the Entry namespace (viz. those starting with "S"/"T"), and no other pages.

Paging @Agent_Isai and @RhinosF1 once again; perhaps @John might be the one to identify what's happening here?

As before, deleted comment below was inadvertently double-posted.

This comment was removed by Routhwick.
Routhwick added a subscriber: Unknown Object (User).Mar 19 2022, 12:17

Since last time (for @Agent_Isai, @RhinosF1, and @John):

  • Tuarène, at the very least, went through two hours after Wednesday's dispatch.
  • Trying to access Entry:sapale has given way to on-and-off browser-based 500 warnings and Miraheze 502s as well since at least yesterday.
  • Not to mention another entry, for kuvale (fungus), was struggling under 500s and 502s. Though the page was registered, I had to delete it twice because of its absence in recent changes (I wonder why that even happens?), and recreated it traditionally. (Its morpheme counterpart had no problems per usual.)

To recap: This only affects a certain subset of titles in the Entry namespace (mainly those starting with "S"/"T"), and no other pages. Extensions involved are Page Forms (Yaron Koren) and DPL3 (@Universal_Omega). I'll keep you updated as more errors occur.

P.S. Re: DPL3, I'll report on a separate "Database error" bug in a matter of hours.

Addenda, afternoon of 20/3 (for @Agent_Isai, @RhinosF1, and @John -- not to mention @Reception123 as I bring him back to this pool): Another new entry page, sofoartar (to hasten/expedite/make haste/be immediate), also struggled under the custom 500s in preview mode this morning, but managed to make it through. (Root table progress still unaffected.) Beyond that, a separate DPL3 filing is on the way pretty soon.

@Routhwick: please stop pinging us. We will get to it when we have a chance.

This is likely an upstream issue though.

Indeed, I think it may be better to report this upstream as I don't see how it could be us?

@Reception123: Just notified upstream (via MW.org's Support desk)--after two days' delay. From here, everyone knows patience is a virtue...

(...Sorry, double-posted below--and I only hit "Submit" just once here. Again, just my luck...)

This comment was removed by Routhwick.

Almost another week later, it's still happening. Today's trouble spot is seremèle, RFM for "vernacular"; trying to save the regular way is a no-go as I type. Code in case the admins need to take a shot at it:

{{Definition/Sandbox|rfm|CL1=nns
|IPA=sɛ./ɹ/ɛ.mɛl|SYL=se, re, mele
|Origin=From|Lang.=Pulaar|Etymon(s)=seremellewal|Source(s)=gsb:fuc:vernacular
|S1=vernacular|N1=everyday speech or dialect
|CL2=a|IPA2=sɛ.ɹɛ.mɛ.li|SYL2=se, re, me, li|S2=vernacular
|CL3=adv|IPA3=sɛ.ɹɛ.mɛ.lu|SYL3=se, re, me, lu|S3=vernacularly
|USG=For the sense of "national language", see ''{{Entry|uzemnovolte}}''.
|HPE=parle|K=Language, Linguistics
|SA=zokugọ:slang/argot/jargon
|Added on={{subst:#time:Y-m-d, H:i}}}}

Plus, as "Bawolff" suggested to me upstream earlier this morning:

you should try and get the webserver error logs from miraheze. 500 & 502 usually means some sort of php error but not always, and can mean a lot of things.

Yaron Koren, in reply:

Yeah, #1 requires error logging or reporting. It doesn't seem Page Forms-related, though, since it doesn't involve forms.

So, if it's not DPL3 nor PF, then whatever else is it? Still waiting otherwise...

THis isn't an upstream issue - from nginx error logs;

FastCGI sent in stderr: "PHP message: PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /srv/mediawiki/w/includes/libs/objectcache/MemcachedPeclBagOStuff.php on line 341PHP message: PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /srv/mediawiki/w/includes/exception/MWExceptionHandler.php on line 318PHP message: PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /srv/mediawiki/w/includes/session/SessionBackend.php on line 221PHP message: PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /srv/mediawiki/w/includes/exception/MWExceptionHandler.php on line 290

Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)...

Looking up the bigger number on Google led me to this StackOverflow discussion from 2015 onward, plus a slew of related threads. As "madz" pointed out there:

For those who are scratching their heads to find out why on earth this little function should cause a memory leak, sometimes by a little mistake, a function starts [to] recursively call itself for ever.

Along with Kristen Waite:

When you see the above error - especially if the (tried to allocate __ bytes) is a low value, that could be an indicator of an infinite loop, like a function that calls itself with no way out:

function exhaustYourBytes()
{
   return exhaustYourBytes();
}

As well as a handful of other users who suggested that raising the memory allocation might fix things a bit. If we proceed with attempting this here, should it be localised (i.e. on my site) or farmwide? (Without breaking anything, of course.)

We can't increase memory limits for only one site

Another week on, and the problem still hasn't resolved itself. Sometimes those pages load, but much of the time they won't.

Today's trouble spots are schraibar (to message/text), schraibiène (messenger), schraibaidi (messaged/sent), and schraibieti (messaged/sent in brief)--all of which actually got properly saved on first edit this afternoon, but the last of which I'm having problems with while trying to make the simplest edit (at press time). Care to get their logs, @John?

Routhwick raised the priority of this task from Normal to High.Apr 13 2022, 01:35

And now for tonight's trouble spot: Although the entry for slenge (slug) actually went through this afternoon (compromises or not), trying to make even the simplest after-the-fact edit has sent me back to 500 territory for the past ~2 hours as I write. Care to get the log, @John?

P.S. Also raising this back to High as the problem at hand is still ongoing, and it won't be Wave 1 of my Dictionary imports unless that's resolved.

P.P.S. Tomorrow might look good for a PF setting request. How much that'll affect our problem pages, I'm not sure yet...

Unknown Object (User) added a comment.Apr 13 2022, 01:44

And now for tonight's trouble spot: Although the entry for slenge (slug) actually went through this afternoon (compromises or not), trying to make even the simplest after-the-fact edit has sent me back to 500 territory for the past ~2 hours as I write. Care to get the log, @John?

P.S. Also raising this back to High as the problem at hand is still ongoing, and it won't be Wave 1 of my Dictionary imports unless that's resolved.

P.P.S. Tomorrow might look good for a PF setting request. How much that'll affect our problem pages, I'm not sure yet...

I was able to make an edit and then a second undo edit to that page without issue.

In my case, I was trying to turn the underdotted eskạrgé into eskargé (snail). Wonder how come you got lucky and I haven't--is it my browser, device, or some other hindrance?

Unknown Object (User) added a comment.Apr 13 2022, 01:58

In my case, I was trying to turn the underdotted eskạrgé into eskargé (snail). Wonder how come you got lucky and I haven't--is it my browser, device, or some other hindrance?

To note: I was unable to use rollback, but manual edit worked both times without issue. I am not sure why not for you... also the error with rollback was almost an instant 500 error, not after awhile, so it is not any timeout either.

Unknown Object (User) added a comment.Apr 13 2022, 02:06

oh, it's the error that is given...

[410434a990e99c6d7d7f7a99] /w/index.php?title=Entry:slenge&action=submit   PHP Fatal Error from line 341 of /srv/mediawiki/w/includes/libs/objectcache/MemcachedPeclBagOStuff.php: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

oh, it's the error that is given...

[410434a990e99c6d7d7f7a99] /w/index.php?title=Entry:slenge&action=submit   PHP Fatal Error from line 341 of /srv/mediawiki/w/includes/libs/objectcache/MemcachedPeclBagOStuff.php: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

Reminded Bawolff upstream (although rather late); let's see how things go from here...

Unknown Object (User) added a comment.Apr 13 2022, 17:40
NewPP limit report
Parsed by mw112
Cached time: 20220413173314
Cache expiry: 3600
Reduced expiry: true
Complications: []
CPU time usage: 8.326 seconds
Real time usage: 17.272 seconds
Preprocessor visited node count: 76365/1000000
Post‐expand include size: 90188/2097152 bytes
Template argument size: 3431/2097152 bytes
Highest expansion depth: 19/40
Expensive parser function count: 3/99
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 65/5000000 bytes
Lua time usage: 1.018/4.000 seconds
Lua memory usage: 1744900/52428800 bytes
Lua Profile:
    Scribunto_LuaSandboxCallback::getExpandedArgument                740 ms       50.0%
    Scribunto_LuaSandboxCallback::find                               220 ms       14.9%
    recursiveClone <mwInit.lua:41>                                   140 ms        9.5%
    <Module:ReplaceSet:3>                                             80 ms        5.4%
    type                                                              80 ms        5.4%
    tostring                                                          40 ms        2.7%
    (for generator)                                                   40 ms        2.7%
    getmetatable <mw.lua:64>                                          40 ms        2.7%
    getExpandedArgument <mw.lua:172>                                  40 ms        2.7%
    <mwInit.lua:41>                                                   20 ms        1.4%
    [others]                                                          40 ms        2.7%
ExtLoops count: 12/200
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 17092.741      1 -total
100.00% 17092.741      1 Template:Definition/Sandbox
 90.64% 15493.298      1 Template:Definition/Position
 15.57% 2662.060    329 Template:ReplaceSet
  6.06% 1035.068      1 Template:Definition/Sidebar
  2.13%  364.137      1 Template:Definition/Word_Family
  1.73%  296.528      1 Template:Definition/Nearby
  1.26%  214.969     18 Template:Entry
  0.49%   84.445      4 Template:Decl
  0.39%   67.412      1 Template:Definition/Arrays
-->

<!-- Saved in parser cache with key constantnoblewiki:pcache:idhash:9182-0!canonical and timestamp 20220413173257 and revision id 15115. Serialized with JSON.
 -->

And now, Bawolff's reply:

Pretty generic OOM error. Note, php OOM errors are unreliable when it comes to what line number they occur at, so there is not necessarily any reason to think it has something to do with MemcachedPeclBagOStuff.php.

Its [sic] still possible that this is triggered by an extension that has some sort of memory leak, or just processes a huge amount of data. You might want to try and generate a minimal test case.

128MB, while definitely a reasonable limit, is borderline on the low side for a memory limit (For comparison, i think WMF uses 666mb). Perhaps it should just be increased. However, whether or not that is an appropriate solution depends on the hosting situation so would be better answered by Miraheze staff (I want to be very clear that it would be 100% reasonable for miraheze staff to say, that due to the way that their hosting is setup, 128mb is what the memory limit has to stay at).

As for line 341 of MemcachedPeclBagOStuff.php (till the case resumes):

$client = $this->syncClient;
Unknown Object (User) added a comment.Apr 14 2022, 00:10

Hi, can you please see if it is better now?

Unknown Object (User) changed the visibility from "Public (No Login Required)" to "Custom Policy".Apr 14 2022, 01:25
Unknown Object (User) changed the edit policy from "All Users" to "Custom Policy".
Unknown Object (User) added a comment.EditedApr 14 2022, 01:32

I did some digging into this. The main issue seems to be the mentioned OOM (which I found is caused by RegexFunctions), with both Loops seemingly playing a part as well, though a bit rare for those ones. I decided to remove all overrides for the Loops extension, so the max limit must remain at 100, due to more than that causing issues with us.

Though it seems that ParserFunctions is another one that due to how much usages there is, is also playing a big part here, causing OOMs, and significantly slowing down the jobs.

Another (unrelated, this one is not causing OOMs, by itself anyway) issue is DPL3, once I tested by disabling ParserFunctions, I got an error for DPL3 sometimes:

2022-04-14 01:28:06 refreshLinks Template:Definition/Arrays pages={"1647":[3034,"dr\u00e8ve"]} rootJobSignature=28e5340e1f5eb5a76c907900dd8ec37c53011775 rootJobTimestamp=20220413202831 triggeredRecursive=1 causeAction=edit-page causeAgent=Routhwick namespace=10 title=Definition/Arrays requestId=da452712a4d937b5d2641c4f (uuid=f759c456ba214c50adf311d4833c64e7,timestamp=1649892120) t=553 error=Wikimedia\Rdbms\DBQueryError: Error 1146: Table 'constantnoblewiki.dpl_clview' doesn't exist (db101)
Function: MediaWiki\Extension\DynamicPageList3\Query::buildAndSelect - Entry:drève
Query: SELECT DISTINCT `page`.page_namespace AS `page_namespace`,`page`.page_id AS `page_id`,`page`.page_title AS `page_title`  FROM `page` INNER JOIN `dpl_clview` `cl1` ON ((`page`.page_id = cl1.cl_from AND (cl1.cl_to = 'rfm=Tovasala' OR cl1.cl_to = 'en' OR cl1.cl_to = '' OR cl1.cl_to = 'rfm=CH')))   WHERE `page`.page_is_redirect = 0 AND `page`.page_namespace = 3034  LIMIT 500

this one is because when DPL3 is installed with ManageWiki, it does not create the VIEW.

Unknown Object (User) edited projects, added Security, Performance, Extensions; removed Configuration.Apr 14 2022, 01:38
Unknown Object (User) moved this task from Backlog to Deployed Extension Bugs on the Extensions board.Apr 14 2022, 01:38
Unknown Object (User) moved this task from Backlog to Short Term on the MediaWiki (SRE) board.
Unknown Object (User) added a comment.Apr 14 2022, 01:45

RegexFunctions has been disabled as it's causing OOMs.

Hi, can you please see if it is better now?

Sure did--and sans RegexFunctions, we actually got an "S" entry (stoazar, "kick") going through Page Forms about an hour ago!

Sadly, the design's been gored away for the time being--we've been through similar territory much earlier on (T7702). Might as well focus on recreating tulajonar myself through PF and reworking the "Definition/Position" code while I can.

Regardless, I'll bring word to Bawolff again in a while.

Unknown Object (User) closed this task as Resolved.Apr 15 2022, 00:49
Unknown Object (User) claimed this task.
Unknown Object (User) changed the visibility from "Custom Policy" to "Public (No Login Required)".
Unknown Object (User) changed the edit policy from "Custom Policy" to "All Users".

Made public since RegexFunctions was disabled for us, which mitigated the issue for you, so considering this task resolved, as it is less issue now. I think we should consider permanent removal of RegexFunctions.

I think we should consider permanent removal of RegexFunctions.

But not before bringing up this advice/pro-tip from RegexFunctions developer "Skizzers" himself, which may help me prevent future catastrophes of such like:

RegexFunctions will not block you from using a terrible regex that causes all sorts of backtracking and uses up a ton of resources. Either optimize your regexes or move to a solution like Scribunto (and lua's pattern matching, which is a lot lighter-weight than regex). If you want to go the former route, there is plenty of information online on how to avoid regex patterns that cause excessive backtracking.

Bolded emphasis mine--and for starters, Jan Goyvaerts of RegExp.info has been there before. That said, I'll do some testing of the trouble spot(s) at ExpandTemplates and remind you on how it's shaping up.

Unknown Object (User) added a comment.Apr 15 2022, 02:06

I think we should consider permanent removal of RegexFunctions.

But not before bringing up this advice/pro-tip from RegexFunctions developer "Skizzers" himself, which may help me prevent future catastrophes of such like:

RegexFunctions will not block you from using a terrible regex that causes all sorts of backtracking and uses up a ton of resources. Either optimize your regexes or move to a solution like Scribunto (and lua's pattern matching, which is a lot lighter-weight than regex). If you want to go the former route, there is plenty of information online on how to avoid regex patterns that cause excessive backtracking.

Bolded emphasis mine--and for starters, Jan Goyvaerts of RegExp.info has been there before. That said, I'll do some testing of the trouble spot(s) at ExpandTemplates and remind you on how it's shaping up.

those depend on the users choice, we do not want it to be possible for users to cause issues for us, so if it is even possible, I do not think we should keep it. We do not want to optimize regexes, since we don't control what users use it for, so it is not a suitable option for us.

Which leaves only Regex Fun--or Scribunto/Lua--as our only options from here. Too bad it had to come down to this--but for what it's worth, I implemented RegexFunctions on the basis of good faith four months ago (as a means of code curbing). Never expected this trouble to arise just from RgxF, but then again...

Unknown Object (User) added a comment.Apr 15 2022, 03:59

Which leaves only Regex Fun--or Scribunto/Lua--as our only options from here. Too bad it had to come down to this--but for what it's worth, I implemented RegexFunctions on the basis of good faith four months ago (as a means of code curbing). Never expected this trouble to arise just from RgxF, but then again...

Yeah I understand. And apologise if it is an inconvenience to you.

As to what might have caused those 500s/502s all along:

  1. The following array setup (from {{Definition/Position}}, already heavy-going by itself) was responsible for the over 300+ calls of {{ReplaceSet}} referenced in T8866#183779, a leadup to the page-loading troubles that ensued; the {{#rmatch}} in the second {{#arraydefine}} might have made it worse across the "S" and "T" entries, whose first letters are the Tovasala-English side's most common.
{{#arraydefine:subposition|{{#dpl:namespace=Entry|category={{#switch:{{{1}}}|rfm=Tovasala|en|#default=English}} terms beginning with {{#if:{{#rmatch:{{PAGENAME}}|^[cC]|yes}}|{{#switch:{{{1}}}|rfm=CH|en=C}}|{{uc:{{#sub:{{#arrayprint:position-sort-2}}|0|1}}}}}}|skipthispage=no|format=,²{ReplaceSet¦²{lc:%TITLE%}²¦-¦¦ȷ́¦j¦ń¦n¦ŕ¦r¦ś¦s¦ý¦y¦ź¦z¦ḷ¦l¦ṛ¦r¦ɓ¦b¦ƈ¦c¦ɗ¦d¦ƒ¦f¦ɠ¦g¦ʝ¦j¦ƙ¦k¦þ¦p¦ѵ¦v¦â¦a¦ā¦a¦ä¦a¦ă¦a¦ạ¦a¦ậ¦a¦é¦e¦è¦e¦ê¦e¦ẽ¦e¦ē¦e¦ë¦e¦ĕ¦e¦ẹ¦e¦ệ¦e¦î¦i¦ĩ¦i¦ī¦i¦ï¦i¦ĭ¦i¦ị¦i¦ō¦o¦ö¦o¦ŏ¦o¦ọ¦o¦ũ¦u¦ū¦u¦ü¦u¦ŭ¦u¦ụ¦u}² • ,}}|•}}{{#arraysort:subposition|asc}}{{#arraydefine:subposition-bi|{{#arraymap:{{#arrayprint:subposition}}|,|*|{{#if:*|{{#sub:*|0|{{#rmatch:*|^{{#switch:{{{1}}}|rfm=[aeious]?c|en|#default=q}}|3|2}}}}}}}}}}{{#arrayunique:subposition-bi}}

In today's overnight maintenance checkup, I took {{ReplaceSet}} out of the DPL call and instead wrapped it around the DPL (just to be safe). Using the traditional but sometimes cumbersome StringFunctions, this is how that segment looks now:

{{#arraydefine:subposition|{{ReplaceSet|{{#dpl:category={{#switch:{{{1|en}}}|rfm=Tovasala|en|#default=English}} terms beginning with {{#switch:{{#sub:{{PAGENAME}}|0|1}}|c|C={{#switch:{{{1|en}}}|rfm=CH|en=C}}|{{uc:{{#sub:{{#arrayprint:position-sort-2}}|0|1}}}}}}|skipthispage=no|ordermethod=sortkey|format=,²{lc:%TITLE%}²,|inlinetext= •}}|-||ȷ́|j|ń|n|ŕ|r|ś|s|ý|y|ź|z|ḷ|l|ṛ|r|ɓ|b|ƈ|c|ɗ|d|ƒ|f|ɠ|g|ʝ|j|ƙ|k|þ|p|ѵ|v|â|a|ā|a|ä|a|ă|a|ạ|a|ậ|a|é|e|è|e|ê|e|ẽ|e|ē|e|ë|e|ĕ|e|ẹ|e|ệ|e|î|i|ĩ|i|ī|i|ï|i|ĭ|i|ị|i|ō|o|ö|o|ŏ|o|ọ|o|ũ|u|ū|u|ü|u|ŭ|u|ụ|u}}|•}}{{#arraysort:subposition|asc}}{{#arraydefine:subposition-bi|{{#arraymap:{{#arrayprint:subposition}}|,|*|{{#switch:{{{1|en}}}|rfm={{#switch:{{#sub:*|0|3}}|ach|cha|che|chi|cho|chu|ech|ich|och|sch|uch={{#sub:*|0|3}}|{{#sub:*|0|2}}}}|en={{#sub:*|0|{{#ifeq:{{#sub:*|0|2}}|qu|3|2}}}}}}}}}}{{#arrayunique:subposition-bi}}
  1. It may or may have not contributed further to the hangups, but this regex for termison detection (from {{Definition/RFM/Headword}}) sure merits honorable mention. (The first segment was tested on various regex-coding sites, hours before press time, but valid enough not to cause excessive backtracking, I think.)
{{#rmatch:{{#arrayprint:hdw}}|^-(([eoa]s?{{!}}[iu]{{!}}ar{{!}}(i[sy](iv)?)?(im{{!}}eum{{!}}it{{!}}ut{{!}}at{{!}}ea(lb(em)?{{!}}n?(k{{!}}j)){{!}}a(sa)?nt{{!}}aik(uit)?){{!}}ait)${{!}}ts)|Termison|{{#rmatch:{{#arrayprint:hdw}}|-$|{{#rmatch:{{#arrayprint:hdw}}|^-|Intra|Pre}}|Suf}}fix{{#rmatch:{{{CL{{#arrayprint:hdw-num}}}}}|[ps]fxd|oid}}}}

As for Miraheze, regex, and 502s? Turns out Cloudflare also found out the hard way several years ago... (H/T Marcin Wanago.)

Moral of the story:

Be very careful if you run a web service that allows users to supply their own regular expressions. People with little regex experience have surprising skill at coming up with exponentially complex regular expressions.

On your side, and mine.

<sigh/> Lots to fix up over the next several weeks. Either that, or a reconsideration--or a Scribunto/Lua stand-in--is in due order.

"Never ends for this Captain, does it?"

On a related note post-resolution (after several days' delay): Subsequent conversions to Scribunto/Lua have still led to similar problems on the Tovasala-English pages whose titles begin with "S"; instances of the recently launched {{Find}} module in the {{Entry}} system are causing the Position-component system and rhyme-page links to go awry:

  • Sometimes, the "Subalphabetical group" Position isn't highlighted;
  • sometimes, the "Sub-subalphabetical group" indexing is four letters deep instead of the intended three;
  • and much of the time, the rhyme-page links have {{{1}}} as the output despite being automatically filled in elsewhere.
  • Furthermore, after hitting the "SK" section, Scribunto/Lua apparently times out while attempting to calculate the remaining widths of the "Subalphabetical group" blocks.

At this writing, subirindar (to communicate) and seiyuv (as the voice of) are ground zero for all four of those symptoms--complete with the "Pages with script errors" tracking category.

"But wait...there's more!" Said symptoms currently overwhelm four entries--sëgguodar ("to enjoy oneself"), selbème ("the object previously mentioned"), selbtrusil ("from/of the subject previously mentioned"), and sinome ("prairie dog")--to the point where they only display "Template:Definition/Sandbox" as their content, placing them in the category "Pages where template include size is exceeded".

Perhaps--finally--this is where Semantic MediaWiki should come in handy (as it once did during the Referata days); paging @RhinosF1. After requesting that at the Stewards' noticeboard à la @BlackHawk, we may as well find out what happens from here.

To @Universal_Omega: If SMW does work, maybe we could bring RgxF back (as I feel no alternatives, especially not even the partially effective {{#dplreplace}}, can compare)?

TL/DR: The more entries per first letter (and the more diacritics detected?), the more the Dictionary's Position system (as currently set up) is proving too much (and still just as demanding/complex) for the automated Module-based approach. Ultimately, the Position component was practically the root of those recent infrastructural issues.