All packsMulti-Tenant Auth & RBAC CoreSolve
prevent last admin removed race condition postgres trigger
Two concurrent demotions can both pass an app-level check
An app-level "don't remove the last owner" check reads the current owner count before either of two concurrent requests writes -- both can pass, leaving zero owners.
What goes wrong
"Don't let an org end up with zero owners" sounds like a simple application-level check: count current owners, refuse the change if it would hit zero. But if two co-owners each demote the other at nearly the same time, both requests can read the owner count before either write commits -- each sees "there's still another owner" and both proceed, leaving the org with zero owners despite the check technically running every time.
Why agents get it wrong
A read-then-write check in application code is the natural way to express this rule, and it passes every sequential test (one demotion at a time) -- the failure is a genuine race condition that only appears under concurrent requests, which most test suites don't attempt unless they're specifically written to simulate simultaneous writes.
What Multi-Tenant Auth & RBAC Core pre-decides
Core decision 13 moves the guarantee into a database trigger (BEFORE UPDATE OR DELETE ON org_members) that locks the org row (SELECT ... FOR UPDATE) before evaluating whether the change would leave the org ownerless -- the row lock forces the second concurrent demotion to wait for the first to commit and re-evaluate against the now-current state, so two concurrent demotions of co-owners cannot both succeed.
Source: ARCHITECTURE.md core decision 13