Conversation
Collaborator
Integration test reportCommit: 8235d22
24 interesting tests: 15 SKIP, 7 KNOWN, 2 flaky
Top 30 slowest tests (at least 2 minutes):
|
andrewnester
approved these changes
Jun 15, 2026
…an fails A failed plan still ran UpgradeToWrite and then returned without Finalize, leaving a header-only WAL on disk. Bail out before UpgradeToWrite when planning has already errored. Also re-check diagnostics after InitForApply, which receives ctx and could log a diagnostic without returning an error. Co-authored-by: Isaac
Name it after the guarantee it checks: a failed plan leaves no WAL. Use a generic test-bundle name. Co-authored-by: Isaac
Co-authored-by: Isaac
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
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.
Changes
When planning failed, the deploy phase still called
UpgradeToWrite(whichwrites the WAL header) and only then returned, never reaching the
Finalizethat would commit or discard it — leaving a header-only WAL on disk.
Bail out before
UpgradeToWritewhen planning has already logged an error, soa failed plan never opens the WAL. Also re-check diagnostics after
InitForApply: it receivesctxand could log a diagnostic without returningan error, so the call site can't prove it won't (
UpgradeToWritetakes noctxand thus can't log, so the earlier check covers it).Why
Related to #5557. The dstate fix in #5606 makes recovery of a leftover WAL
safe; this stops a failed plan from creating one in the first place.
Tests
bundle/deploy/wal/two-failed-deploys: a deploy creates the job, then aninjected fault on the plan-stage refresh GET makes the next two deploys fail
while planning — no WAL is left and the final deploy recovers. Confirmed to
fail when the fix is reverted.
This pull request and its description were written by Isaac.