MediaWiki: 1.32.6
Cargo: 2.3.1 (400a3f0)
PageForms: 4.5.1 (b993d37)

we've been haunted quite a while with seemingly erratic cargo duplicates on our production platforms. finally i found these circumstances to always reproduce 3 duplicate rows of a page via PageForms' formedit action. maybe this helps someone identify their cargo duplicate causes.

1. an extension that calls $wikipage->getParserOutput( new ParserOptions, null, true ); in a PageContentSave Hook (dont know if other Hooks are possible, too)
2. $wgMainCacheType = CACHE_NONE; in LocalSettings.php
3. in a cargo_declare a field with String and in the PageForms Form definition an input of type textarea that stores to the same cargo field (see below)
4. an empty jobQueue
5. a POST request to action=formedit for a page that includes a cargostore parser function; the wikitext must contain text that is longer than 300 chars as the db column is defined with VARCHAR(300)

so after some step debugging i found that 1. creates a dynamic refreshLink job that gets called at the end of the POST request to the action=formedit. this refreshLink job triggers the parser (I assume 2. is crucial here). the parser runs the CargoStore with db transactions leading to duplicates, because the SQL check fails in 3. and because the CargoStore::$settings['origin'] flag is not cleared after the original db transaction.

so in our case, with sloppily defined cargo declare/pageforms templates/forms, whenever theres a refreshLink job for a cargo page at the top of the jobqueue at the end of the request, this will trigger duplicates when another cargo page is updated via a PageForms' formedit.

is there a way to clear the CargoStore::$settings['origin'] flag after the db transaction?

Template: Activity

{{#cargo_declare:
_table=activity
|description=String
}}

{{#cargo_store:
_table=activity
|description={{{description|}}}
}}

Form:Activity

{{{field|description|input type=textarea}}}