@Arlolra Thank you for the quick move. In an attempt to help you diagnose the problem (or verify the patch works fine), here is a list of other URLS suffering for the same symptom:

• https://en.wikipedia.org/api/rest_v1/page/mobile-sections/List_of_modern_Hangul_characters_in_ISO%2FIEC_2022%E2%80%93compliant_national_character_set_standards
• https://fr.wikipedia.org/api/rest_v1/page/mobile-sections/Liste_des_membres_du_magistrat_de_Bruxelles
• https://de.wikipedia.org/api/rest_v1/page/mobile-sections/Ewige_Tabelle_der_UEFA_Europa_League_und_des_UEFA-Cups
• https://ru.wikipedia.org/api/rest_v1/page/mobile-sections/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D1%83%D0%B3%D1%80%D0%BE%D0%B6%D0%B0%D0%B5%D0%BC%D1%8B%D1%85_%D0%B2%D0%B8%D0%B4%D0%BE%D0%B2_%D1%86%D0%B2%D0%B5%D1%82%D0%BA%D0%BE%D0%B2%D1%8B%D1%85_%D1%80%D0%B0%D1%81%D1%82%D0%B5%D0%BD%D0%B8%D0%B9
• https://ar.wikisource.org/api/rest_v1/page/html/%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE_%D8%A7%D9%84%D9%8A%D8%B9%D9%82%D9%88%D8%A8%D9%8A

@Arlorla Thank you so much for your effort. I'm not sure if this (kind of) problem is old or if this is a regression because at the same time we tend to make MWoffliner more strict. What is sure is that it impacts maybe 40% of all wikis and that we barelly can scrape fully a big Wikipedia anymore.

@Arlolra I allow myself to ping you on this as the impact is super high for us and I don't know who else to ping. That said, not sure if this is an error in Parsoid or in the API service itself.

I have move from 6 slots to 10, hopefully this won't destabalised the server.

@ArielGlenn Still a problem?

The root problem is in the wiki code (free text in place of size in pixel)... but probably Parsoid should not generated broken HTML of it.

@Aklapper This bug is a serious one for the Kiwix team as it impacts many (proeminent) Wikimedia wikis and make our whole scraping dying because the backend does not deliver. Any chance someone could have a look why such given URLs simply fail in the backend?

Mobile API is impacted as well, see for example https://de.wikipedia.org/api/rest_v1/page/mobile-sections/Chronik_der_COVID-19-Pandemie_in_den_Vereinigten_Staaten_2020

@ssastry thx a lot!

@arlorla Great to see a patch here. Thx! A few users had reported the problem on our side over the years. What is the timeline for prod? https://ru.wikipedia.org/api/rest_v1/page/html/%D0%9D%D0%B0%D0%BC%D0%B8%D0%B1%D0%B8%D1%8F#mwAdg seems to be still buggy.

@Arlolra Indeed and it seems to work fine in the ZIM as well http://library.kiwix.org/wikisource_fr_all_maxi/A/De_la_litt%C3%A9rature_des_n%C3%A8gres/4. Thx.

@Krinkle Thx, I'm still in touch with a developer of this custom version of MathJax extension and he will try to load the MathJax js code within the ResourceLoader.

@Krinkle I have mailed someone at Proofwiki and it was given to me the following link (seems to be and older Version of the MathJax extension) https://www.mediawiki.org/w/index.php?title=Extension:MathJax&oldid=1184913. Not sure what would be the next step. Would that simply work if they update the extension to the latest version?

Might that be that this ticket has been invalided by the deprecation of server-side Graphoid charts rendering?

A few days ago a user has open a third ticket (https://github.com/openzim/mwoffliner/issues/1402) about that on MWoffliner. I don't really understand why this old bug, which seems easy to fix, has not been tackled so far.

@Krinkle I thought first from https://proofwiki.org/wiki/Special:Version that it was https://www.mediawiki.org/wiki/Extension:MathJax... but now I have a big doubt.

@Arlolra Thx for the patch. Hopefuly soon in prod!

We came back to this ticket on Kiwix side with https://github.com/kiwix/kiwix-android/pull/2562#issuecomment-767382951

@Audiodude and me are the maintainers. I got an email to inform me about this ticket.

An other example: here is the Classic rendering:
https://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D0%BC%D0%B8%D0%B1%D0%B8%D1%8F#%D0%A1%D0%BC._%D1%82%D0%B0%D0%BA%D0%B6%D0%B5

Someone has fixed the problem in the wiki source at https://li.wiktionary.org/w/index.php?title=Wiktionary%3AVeurblaad&type=revision&diff=645102&oldid=628893.

Still a new case here: https://es.wikipedia.org/api/rest_v1/page/html/Anexo:Baloncesto_en_los_Juegos_Mediterr%C3%A1neos_de_1951, 15 days after image renaming on Commons (https://commons.wikimedia.org/w/index.php?title=Special:Log&page=File%3AFlag+of+Egypt+%281922%E2%80%931958%29.svg), the rendered HTML still points to a the wrong/old/404 thumbnail.

@ssastry Thank you very much for the analysis.

@Aklapper I tend to think the problem is real but maybe has been wrongly reported.

I have found the password for "WP 1.0 bot" (Thank you backup!)

@ArielGlenn Oh yes... sounds a good candidate. Thx for linking both tickets!

@ArielGlenn Seems you are right. Indeed Stripped from the link, see https://el.wikibooks.org/api/rest_v1/page/html/inux_%CE%B3%CE%B9%CE%B1_%CE%B1%CF%81%CF%87%CE%AC%CF%81%CE%B9%CE%BF%CF%85%CF%82%2F%CE%93%CE%B9%CE%B1%CF%84%CE%AF_Linux%3B

@ArielGlenn I have put the online link as a reference. It is not deleted and if there is a typo, where (I can not find it)? You can see the problem differently: how to get the Parsoid output via REST api for this very specific article?

@Andrew mwoffliner1 & mwoffliner3 have been re-created. Hope this solves your problem :)

@ema not really this is case which had to be handled in MWoffliner. This is all.

@Andrew Then good to me. Would deleting the instance and recreating them be good enough to solve our problem? Or should we follow an other procedure?

@Andrew Hi Andrew. About which VMs are with talking about exactly? mwoffliner1, mwoffliner2 and mwoffliner3? It is possible for us to invest time to recreate them but I would like to secure with you than we won't get weaker hardware. This is really critical point for us that they get really similar hardware (like mwoffliner5).

@CDanis We get many HTTP 429 errors from the rest(base) API if we scrape with nodes outside the VPS cluster. Really a hassle to deal with. It seems to me we are impacted... But maybe I get something wrong.

FYI: Because it seems there is a knowledge/communication gap about openZIM/Kiwix dumping solution, a Tech talk is currently being planned (probably in August) https://phabricator.wikimedia.org/T255392. If you have questions/concerns/remarks, please make comments on that ticket. I will secure that the presentation address them.

I can only emphasis that a ticket which does not transparently explain the problem which is tried to be solved is going to be successfuly only by chance. Therefore, this is probably my last comment on this as we run here a discussion being blind. One of thing I heard is that that dumps might have to include the Parsoid sementic tags, which is not the case for the dumps issued by MWoffliner (MWoffliner remove them). If this is the case, a POC can be done within a few hours to avoid remove them, we can ever just store the raw HTML issued from the API JSON.

I believe I don't understand why additional HTML dumps are necessary, but like @ArielGlenn has written we do all of this already on a monthly base:

• Scraper: https://github.com/openzim/mwoffliner
• Scraping farm: https://farm.openzim.org
• Resulting ZIM packages files: download.kiwix.org/zim (via HTTP, FTP, RSYNC, BITTORRENT)
• Online version (curently a bit unstable sorry): https://library.kiwix.org

@aborrero Thank you very much. Everything works like a charm now!

@Andrew I have been able to recreate mwoffliner2 properly. I believe 4 VCPUs and 8GB or RAM are missing in the quota.

@Andrew Thank your very much for this! I have been able to delete mwoffliner1 and recreate it successfully with a xlarge-xtradisk profile. The VM is up and running. I wanted to recreate mwoffliner3 the same way, deleted it but failed to create a new xlarge-xtradisk instance. It seems the quota is not proper (too low). Do I'm wrong somewhere?

@Aklapper Thx for pointing me to this, I have updated the task with the expected information.

@abi_ Thank you!