akvo / akvo-mis / #781

89%

main: 89%

Pull #284

coveralls-python

[#272] Answer a lost level-add race with 400, not 500

Copilot's review of the levels screen raised four points; three of them
were real and are addressed here.

`perform_create` reads the tenant's deepest level and writes max + 1
with nothing holding the gap, so two adds in flight together both pick
the same depth and the loser trips `unique_level_per_tenant`. That
bubbled out of DRF as a 500. It is now caught and answered as a 400
telling the caller to reload.

The savepoint around the create is not decoration: an `IntegrityError`
caught without one leaves the connection unusable for the remainder of
the transaction, so the rejection could not be built at all if a
transaction were ever open around the request. Locking the levels table
instead would have been the wrong trade for a screen a tenant uses once,
during onboarding.

Reaching that race from the UI took no contrivance. Both Save buttons
carry `loading={saving}`, which antd uses to swallow clicks while a
request is in flight, but the inputs' `onPressEnter` had no such
protection — two quick presses of Enter were a live double-submit. The
handlers now refuse to fire while a save is outstanding.

The same handlers trim the name and refuse a blank result. This is not
the validation; DRF's `CharField` already trims and rejects, which is
why a name of spaces could never have been stored. It is about what the
person sees: previously "   " passed the `!newName` guard, cost a round
trip, and came back as the generic error toast rather than as a button
that had stayed disabled.

Copilot's fourth point — that anchoring `/levels` also stopped it
matching `/levels/` — describes a real change in behaviour, but nothing
calls the endpoint with a trailing slash. The web client uses
`api.get("levels")` and the mobile app never touches it. Precision was
the reason for the anchor, so it stands.

Both new tests were checked against the unfixed code first: without the
savepoint the race test errors out, and witho... (continued)

5751 of 6647 branches covered (86.52%)

Branch coverage included in aggregate %.

10919 of 12120 relevant lines covered (90.09%)

0.9 hits per line