akvo / akvo-mis / #710

88%

main: 88%

push

coveralls-python

[#255] Send submission_key from the webform

The duplicate window is not mobile-specific. submitFormData catches the error,
shows a toast, and re-enables the submit button, so a request that succeeded
server-side but died in the proxy on the way back leaves the user looking at
"something went wrong" next to a live button. They press it again.

Mint the key into a useRef so retries reuse it, and clear it only after the
backend confirms. Minting inside the payload literal would give every retry a
fresh key and restore the bug.

Known gap: the key is cleared only on success, so a user who corrects an answer
after a failed submit and resubmits sends the same key, and the guard swallows
the edit while reporting 200. The key identifies a submission's content, so any
edit must invalidate it -- clear the ref in onChange. Documented in APP-255
D-12; not fixed here. The mobile app does not carry this gap: FormPage mints a
fresh key on every write.

Additive on both tiers. A cached bundle omits the field and behaves exactly as
today, because submission_key is required=False and null=True.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

[#255] Align APP-255 with the implementation

The design doc drifted from what shipped in three places:

- D-11 gained the transaction.atomic() savepoint around the INSERT, with the
  reason: ATOMIC_REQUESTS is off today so the recovery query runs, but turn it
  on and the IntegrityError poisons the request transaction and the recovery
  raises TransactionManagementError instead. The savepoint keeps the clause
  reachable either way. The `if not key: raise` re-raise keeps an unrelated
  IntegrityError from being swallowed as a phantom replay.
- D-12 records the edit-after-failure gap: clearing the webform's key only on
  success means a corrected answer resubmitted after a lost acknowledgement is
  swallowed by the guard and reported as saved. The fix and its trade-o... (continued)

5669 of 6577 branches covered (86.19%)

Branch coverage included in aggregate %.

10681 of 11913 relevant lines covered (89.66%)

0.9 hits per line