Skip to content

Keep zones ready when DNS record pruning fails - #563

Closed
gi8lino wants to merge 1 commit into
masterfrom
codex/keep-zone-ready-on-prune-failure
Closed

Keep zones ready when DNS record pruning fails#563
gi8lino wants to merge 1 commit into
masterfrom
codex/keep-zone-ready-on-prune-failure

Conversation

@gi8lino

@gi8lino gi8lino commented Jul 31, 2026

Copy link
Copy Markdown
Member

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 Ready condition, so a temporary prune failure blocks every managed DNSRecord in that Zone even though:

  • the Cloudflare account is valid;
  • the Zone was resolved successfully;
  • the Zone ID is available; and
  • normal record reconciliation may still work.

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:

  • Keep Ready=True after the account and current Zone ID have been validated.
  • Report the latest pruning result through a new Pruned condition.
  • Use PruneSucceeded and PruneFailed condition reasons.
  • Continue requeueing at the configured retry interval when pruning fails.
  • Remove a stale Pruned condition when pruning is disabled.
  • Expose Pruned as an additional column in kubectl get zones.
  • Regenerate the Zone CRD manifest.

Account lookup and Zone resolution errors still set Ready=False; only optional prune failures are treated as non-blocking.

Resulting behavior

Situation Ready Pruned
Pruning disabled True absent
Pruning succeeds True True
Pruning fails True False
Account or Zone resolution fails False unchanged/not applicable

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=1
  • go test ./... -run '^$' -count=1
  • go vet ./...
  • git diff --check
  • Verified that the previous PruneReady name is absent from the codebase

@gi8lino
gi8lino marked this pull request as ready for review July 31, 2026 12:50
@gi8lino

gi8lino commented Jul 31, 2026

Copy link
Copy Markdown
Member Author

forget this, better solve this by checking if a object is in deleting phase...

@gi8lino gi8lino closed this Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant