fix: suspending KafkaBackup now suspends the underlying CronJob#25
Merged
Conversation
Suspending a KafkaBackup left its previously-created CronJob with suspend: false, so scheduled backups kept running. Always apply the CronJob when a schedule is set so the suspend flag reaches the live resource, report a BackupSuspended condition, and clear nextScheduledBackup while suspended. Add a reconciler-level regression test that runs reconcile_backup against a mock API server and asserts the CronJob patch carries the CR's suspend value, plus a builder-level suspend propagation test. Release 0.2.7. Fixes #24. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
Summary
Fixes #24 — setting
spec.schedule.suspend: trueon aKafkaBackupleft the previously-created CronJob withsuspend: false, so scheduled backups kept running.The reconciler only applied the CronJob when the schedule was not suspended, so the (already correct)
suspendvalue frombuild_backup_cronjobnever reached the live resource. This PR:spec.scheduleis set, sospec.schedule.suspendpropagates to the live CronJob via server-side apply.Readycondition with the newBackupSuspendedreason while suspended, and clearsstatus.nextScheduledBackup(explicitnullin a merge patch, since the status type skipsNonefields when serializing).version/appVersion, CHANGELOG) —scripts/release-gate.shpasses locally.Reproduction / verification
Reproduced on a kind cluster before the fix: created a
KafkaBackupwith a*/1 * * * *schedule, patchedsuspend: true, and observed the CronJob stay atsuspend: falseand spawn a backup Job a minute later. With the fix, the suspend flag propagates on the next reconcile.Tests
test_reconcile_propagates_suspend_to_cronjob/test_reconcile_applies_active_cronjob_when_not_suspended(newtests/integration/reconcile_backup_test.rs): runs the realreconcile_backupagainst atower-testmock API server, recording every request — asserts the CronJob PATCH carries the CR's suspend value and the status reflects suspension. Verified the suspended-path test fails against the pre-fix code.test_backup_cronjob_propagates_suspend: builder-level check thatspec.schedule.suspendmaps ontoCronJob.spec.suspend.🤖 Generated with Claude Code