secret/database: fix bug where too many wal deletes are deferred #16686
Conversation
This file contains 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
fairclothjm
approved these changes
Aug 11, 2022
austingebauer
approved these changes
Aug 11, 2022
calvn
approved these changes
Aug 11, 2022
calvn
reviewed
Aug 11, 2022
Co-authored-by: Calvin Leung Huang <[email protected]>
This was referenced Aug 11, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes a small bug in the
initQueuefunction where a WAL write test is performed prior to starting the database secret engine caused a lot of delete wal calls to be queued. To fix the bug we simply check if there is also no error after writing WAL.When Vault is starting up, its storage is read only, so writes will produce an error. The current code checks if a WAL ID is returned after calling
PutWal, but this function always returns a WAL ID so it defers a delete call. Since an error is also returned, it then loops and tries again. If start up is taking an excessive amount of time, this bug will queue up a delete wal every 10ms until Vault's storage accepts writes. This is amplified if you have many database secret engines.