Fix concurrent posts racing past quota (issue #010)

make_room_for() read usage before any write lock was held, so concurrent
requests could each read stale data and both conclude "this fits" -
confirmed reproducible (measured 616 bytes over a 1551-byte quota with 5
truly concurrent posts).

Fix: force SQLite to acquire its write lock immediately via a no-op UPDATE
on the user's UserProfile row, before reading `used`, wrapped in
transaction.atomic() through the subsequent Artifact.objects.create() so
the lock is held across the whole eviction+insert sequence. Added a 20s
DB timeout as headroom for legitimate contention.

Deliberately no retry/backoff logic - this project's actual load (a
low-volume self-hosted tool) doesn't need it, and SQLite has no row-level
locking regardless, so quota-affecting writes serialize globally either
way. Did fix a real bug found while verifying this: exception handling
around artifact creation only caught QuotaExceeded, so a genuine lock
timeout left the just-written file orphaned on disk - both call sites now
clean up on any exception.

Verified live against the real dev instance (twice, with 5 truly
simultaneous posts against a tight quota) rather than via an automated
test - Django's in-memory shared-cache test database uses a different,
non-retryable SQLite locking model that fails for reasons unrelated to
this fix's correctness.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
peter 2026-09-02 15:22:37 +01:00
parent 696cfe7d65
commit d1b6a19eb3
4 changed files with 195 additions and 36 deletions

View file

@ -61,6 +61,14 @@ DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": os.environ.get("DATABASE_PATH", DATA_DIR / "db.sqlite3"),
# SQLite has no row-level locking; concurrent quota-affecting writes
# (see storage.make_room_for) serialize on the whole database.
# Without an explicit timeout, Python's sqlite3 default (5s) is often
# enough, but a contended request past that raises "database is
# locked" as a raw 500 instead of just waiting. 20s comfortably
# covers this app's actual write latency (milliseconds) under any
# realistic concurrency at this project's scale.
"OPTIONS": {"timeout": 20},
}
}