Backport of secret/database: fix bug where too many wal deletes are deferred into release/1.11.x #16694
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.
Backport
This PR is auto-generated from #16686 to be assessed for backporting due to the inclusion of the label backport/1.11.x.
The below text is copied from the body of the original PR.
This fixes a small bug in the
initQueue
function where a WAL write test is performed prior to starting the database secret engine caused a lot of delete wal calls to be queued.When Vault is starting up, it's storage is in 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.Overview of commits