Repository navigation
Lock the queue when a persist write fails (#161) - #164
Merged
Merged
Conversation
Enqueue and dequeue already write the log before changing memory (#163). A failed write therefore returns 500 and leaves the queue unchanged. Nothing covered a write that fails outright once persist.dat is already at the size cap, so reversing that order would again drop an item on a 500 dequeue and keep a rejected enqueue. The regression test fills the log to the ulimit cap, then checks that a 500 dequeue and a 500 enqueue leave length unchanged and that only the accepted item is recovered after restart.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #161
Summary
#163 already persists before mutating memory. That is why a full
PERSISTvolume no longer delivers rejected items or drops a dequeued item. Nothing locked the case where the log is already at the size cap, so a later reorder would bring #161 back. This adds that regression test.Evidence
saveEvent, the same loop went red:dequeue at cap -> 500 length 1 -> 0, then a rejected enqueue stayed queued (length=1).After:
deno test --allow-all tests/short_write_test.ts --filter '#161'passes. On a 2 MiB HFS+ RAM disk filled to the allocation-block boundary, dequeue and enqueue both return 500 withNo space left on device (os error 28)and length stays 1; after space is freed the accepted item is delivered.Merge Danger
Door: two-way
Test-only. Revert the commit to drop the lock; runtime behaviour is unchanged.
Blast Radius: tests
The new test starts a real server under
ulimit -f, the same seam as the #160 short-write tests.