+16
−0
Loading
QuotaAvailable and ClaimServer run as two separate statements, so the count read is not serialized against a concurrent claim's UPDATE: two claims by one user for two different ownerless servers can both pass the gate and both succeed, leaving the user one server over quota. It is low severity — quota over-provisioning under a deliberate burst, not an authorization, ownership, or isolation break, since each server is still claimed atomically via UPDATE ... WHERE owner_id IS NULL. Closing it requires Postgres transaction semantics (advisory-xact-lock on the user, or SERIALIZABLE with retry) folding the gate into a single repo method — verifiable only against a real Postgres, not the hermetic fakeRepo suite. Documented at QuotaAvailable with back-references from the two claim gates (handleClaim and the internal UUID claim) rather than patched blind.