fix: atomic burn-after-read claim (#58) #77

Merged
poslop merged 1 commits from issue-58-burn-race into main 2026-09-09 14:25:06 +00:00
Owner

Makes burn-after-read deletion atomic so exactly one concurrent reader receives content.

  • SoftDelete is now a conditional UPDATE (WHERE deleted_at IS NULL) checked via RowsAffected; the winner of the delete wins the read
  • RegisterRead returns an admitted flag; for burn-after-N pastes reads_used is incremented via a conditional UPDATE (reads_used < reads_limit), so the last read cannot be consumed twice
  • API GET, HTML page, and /raw all return 404 when the reader loses the burn claim
  • OpenStore pins the SQLite pool to 1 connection (concurrent pooled writes surfaced SQLITE_BUSY as spurious 500s)
  • Regression tests: 24 parallel readers of a burn paste (exactly one gets content); 30 parallel readers vs a 3-read budget (exactly 3 admitted, then 404). Pass with -race.

Closes #58

Makes burn-after-read deletion atomic so exactly one concurrent reader receives content. - SoftDelete is now a conditional UPDATE (WHERE deleted_at IS NULL) checked via RowsAffected; the winner of the delete wins the read - RegisterRead returns an admitted flag; for burn-after-N pastes reads_used is incremented via a conditional UPDATE (reads_used < reads_limit), so the last read cannot be consumed twice - API GET, HTML page, and /raw all return 404 when the reader loses the burn claim - OpenStore pins the SQLite pool to 1 connection (concurrent pooled writes surfaced SQLITE_BUSY as spurious 500s) - Regression tests: 24 parallel readers of a burn paste (exactly one gets content); 30 parallel readers vs a 3-read budget (exactly 3 admitted, then 404). Pass with -race. Closes #58
poslop added 1 commit 2026-09-09 14:19:06 +00:00
fix: atomic burn-after-read claim (#58)
CI / docker (pull_request) Skipped
CI / test (pull_request) Successful in 20s
78374b2d49
SoftDelete now reports whether it performed the delete (conditional
UPDATE ... WHERE deleted_at IS NULL checked via RowsAffected).
RegisterRead returns an admitted flag: legacy burn pastes admit exactly
one reader (the atomic soft-delete winner), and burn-after-N pastes
increment reads_used via a conditional UPDATE guarded on
reads_used < reads_limit, so concurrent readers cannot both consume the
final read. API, HTML, and raw read paths return 404 when the reader
loses the burn claim; content is never served twice.

OpenStore pins the SQLite pool to one connection: concurrent writes on
separate pooled connections surfaced SQLITE_BUSY as spurious 500s
instead of serializing.

Adds concurrency regression tests: 24 parallel readers of a burn paste
(exactly one receives content, none of the others leak it) and 30
parallel readers vs a 3-read budget (exactly 3 admitted, then 404).
poslop merged commit bdd5235f2e into main 2026-09-09 14:25:06 +00:00
Sign in to join this conversation.