Fix message store crash when file deleted during concurrent GC#15411
Merged
michaelklishin merged 1 commit intorabbitmq:mainfrom Feb 9, 2026
Merged
Conversation
Collaborator
Author
|
I appreciate the review @lhoguin - thanks! |
michaelklishin
requested changes
Feb 6, 2026
Handle case where garbage collector asynchronously deletes a file from
FileSummaryEts while a write operation is trying to reference it. This
race condition can occur during high load (e.g., maintenance drain with
heavy queue leadership transfers) when:
1. Message exists in index with ref_count=0, file=N
2. File N is marked for deletion (valid_total_size=0)
3. GC asynchronously deletes file N from FileSummaryEts
4. Write request arrives for the message
5. ets:lookup(FileSummaryEts, N) returns []
6. Code crashes with {case_clause, {false, []}}
The fix adds two new case clauses to handle this scenario:
- {false, []} - Delete stale index entry and write fresh copy
- {false_if_increment, []} - Ignore write (client dying)
This follows the same pattern as existing clauses that handle files
being deleted or locked. Since ref_count=0, the old copy is orphaned
and safe to discard.
Observed in production during maintenance window causing 969 queue
process crashes. See ticket V2090892319.
e1fb5b7 to
8f27887
Compare
michaelklishin
approved these changes
Feb 7, 2026
lhoguin
approved these changes
Feb 9, 2026
Contributor
lhoguin
left a comment
There was a problem hiding this comment.
Looks fine.
Tbh I think this write_action clause may only be necessary anymore when there's older data because we index_delete on remove now. Or perhaps I just missed something.
michaelklishin
added a commit
that referenced
this pull request
Feb 9, 2026
Fix message store crash when file deleted during concurrent GC (backport #15411)
lukebakken
pushed a commit
to lukebakken/rmq-rabbitmq-server
that referenced
this pull request
Mar 17, 2026
…g-file-case Fix message store crash when file deleted during concurrent GC (cherry picked from commit 5304c89)
lukebakken
pushed a commit
to lukebakken/rmq-rabbitmq-server
that referenced
this pull request
Mar 17, 2026
…g-file-case Fix message store crash when file deleted during concurrent GC (cherry picked from commit 5304c89)
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
3 participants
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.
During high load operations (such as maintenance drain with heavy queue leadership transfers), the message store can crash with
{case_clause, {false, []}}inwrite_action/3at line 1121.This occurs when:
ref_count=0referencing file Nvalid_total_size=0)FileSummaryEtsets:lookup(FileSummaryEts, N)returns[]{false, []}The crash cascades to queue processes attempting to write messages.
Solution
Add two new case clauses to
write_action/3to handle files already deleted by GC:{false, []}- Delete stale index entry and write fresh copy to current file{false_if_increment, []}- Ignore write when client is dyingThis follows the same pattern as existing clauses that handle files being deleted or locked. Since
ref_count=0, the old copy is orphaned and should be safe to discard.