Page MenuHomeMiraheze

Periodic disruption to Scribunto scripts that use Cargo
Closed, ResolvedPublic

Description

https://frackinuniverse.miraheze.org has some Scribunto modules (Lua scripts) that use mw.ext.cargo (as described here: https://www.mediawiki.org/wiki/Extension:Cargo/Other_features#Lua_support ), for example https://frackinuniverse.miraheze.org/wiki/Module:AutomaticInfoboxItem

Sometimes the pages that were working fine yesterday get the following error:
Lua error in Module:AutomaticInfoboxItem at line 44: attempt to index upvalue 'cargo' (a nil value).
(the script has local cargo = mw.ext.cargo)

Manually using purge on the page immediately corrects this 1 page, but readers don't know that, they assume that page is unavailable and are complaining "your wiki is broken".
This happens rarely, but the error gets cached, leaving the affected pages broken until purged manually.

My assumption is, as a part of some maintenance procedure, Cargo is being sometimes disabled (in LocalSettings?) for some reason? And any page that renders during this period of time (even if it's just 2-3 seconds) becomes broken. This particular wiki is heavily reliant on Cargo and less than 1% of pages are usable without it.

Event Timeline

dross triaged this task as Normal priority.Jan 17 2022, 09:26
dross added projects: MediaWiki (SRE), Extensions.
Unknown Object (User) added a comment.Jan 18 2022, 07:52

Is this still happening? There was intermediate times cargo was disabled on a single mediawiki server after the migration to debug some performance issues which has since been improved. I apologise for the inconvenience and it shouldn't be disabled again.

It is not happening right now, but this is not specific to migration. It happened many times before the migration.

Unknown Object (User) added a comment.Jan 18 2022, 08:45

It is not happening right now, but this is not specific to migration. It happened many times before the migration.

There was some debugging by Reception123 I believe also pre-migration that disabled it to test performance. Again we apologise for the issue caused.

Let's close this for now, since disabling Cargo is not a periodic process.

In the future, if Cargo needs to be disabled, I recommend setting the affected wiki to readonly mode beforehand, because it will prevent incorrectly parsed pages (while Cargo is unavailable) from being written into CACHE_DB parser cache.

Reception123 claimed this task.
Reception123 subscribed.

per above.