zrok
zrok copied to clipboard
Resource Limit Race Condition
When creating resources (shares or environments) quickly (programmatically, in a loop) the resource limits are not always correctly enforced.
Naively I would expect that we could fix this pretty simply by way of pessimistic locking (SELECT ... FOR UPDATE
), but that isn't supported by SQLite.
So, we're going to need to figure out another locking mechanism that works across both database types.
For v0.4
, we can (and probably should) conditionally use a different storage implementation for PostgreSQL versus SQLite. The PostgreSQL version can do the SELECT ... FOR UPDATE
, and the SQLite version can retain the current behavior. The race condition doesn't really hurt anything beyond allowing programmatic creation of resources beyond the configured limit.
Larger installations (that are more likely to be concerned with enforcing limits) can use PostgreSQL with the better behavior, closing the race condition hole.