Found the root cause, I think.

It appears there's already a unset( CargoStore::$settings['origin'] ); after the call to CargoUtils::parsePageForStorage in CargoPopulateTableJob.php so that doesn't fix that issue.

Interesting: Adding that line you suggested fixes the bug conditionally, but I'm not sure about the conditions.

The unique column itself doesn't trigger the issue, only the implicitly stored one with an explicit empty value triggers it. (Just tested.)

Thank you, that explains that part at least. We have indeed implemented a workaround that makes the uid field both mandatory and unique (in our real cargo tables that were hit by this issue).

As a test, I've done the following:

@Yaron_Koren Sorry for the late response! Yes, I believe this can be closed.

I don't have much experience with MediaWiki extensions, but this simple patch seems to work.

Yes, we use format=template extensively, and it looks like this was happening with templates using Cargo queries & format=template. Someone on the MediaWiki Discord also warned me about using REL1_XY branches of Cargo; thanks for the heads up.

Thank you! That seems to have fixed the issue, and both Wikitext and HTML are working again in intro/outro/default from what I can tell.

@Yaron_Koren Thanks for the explanation! Yes, using regular wikitext for the start and end of tables doesn't seem to work anymore after my patch, so it's not ideal. However, until recently, both wikitext and HTML was actually working fine on our wiki. Version 3.6.1 was the last release version where all was fine; one of the commits thereafter made the HTML stop working. Was it perhaps a necessary change to avoid some security issues, and/or double-parsing? (I see some commits related to double-parsing some time after 3.6.1.)

The default parameter seems to suffer from the same issue and can be fixed similarly:

I would like to add this extension to our wiki (bg3.wiki) but the big red warning on the extension page, saying that its future is unclear, made me worried and led me here.

Here's a fix: