Keep zones ready when DNS record pruning fails - #563
Closed
gi8lino wants to merge 1 commit into
Closed
Conversation
gi8lino
marked this pull request as ready for review
July 31, 2026 12:50
Member
Author
|
forget this, better solve this by checking if a object is in deleting phase... |
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.
Problem
The Zone reconciler currently treats DNS record pruning as part of the Zone's readiness check. If the Cloudflare DNS Records API returns a transient error while listing or deleting records, the controller marks the entire Zone
Ready=False.DNSRecord reconciliation is gated on the Zone's
Readycondition, so a temporary prune failure blocks every managed DNSRecord in that Zone even though:This was observed with intermittent HTTP 522 responses from Cloudflare. A background cleanup failure therefore became a zone-wide reconciliation outage.
Solution
Separate Zone usability from the result of the optional pruning pass:
Ready=Trueafter the account and current Zone ID have been validated.Prunedcondition.PruneSucceededandPruneFailedcondition reasons.Prunedcondition when pruning is disabled.Prunedas an additional column inkubectl get zones.Account lookup and Zone resolution errors still set
Ready=False; only optional prune failures are treated as non-blocking.Resulting behavior
This keeps managed DNS records reconciling during transient prune/API failures while preserving clear status visibility and automatic retries.
Validation
go test ./internal/controller -run '^TestSetZoneReadyConditions$' -count=1go test ./... -run '^$' -count=1go vet ./...git diff --checkPruneReadyname is absent from the codebase