mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-09-28 10:45:44 +00:00
57bddf7f23
Run the E2E test on kind / setup-test-matrix (push) Failing after 3s
Scorecard supply-chain security / Scorecard analysis (push) Skipped
e2e-test-kind.yaml / extract (push) Failing after 9s
Run the E2E test on kind / get-go-version (push) Failing after 10s
Run the E2E test on kind / build (push) Skipped
Run the E2E test on kind / run-e2e-test (push) Skipped
push.yml / extract (push) Failing after 6s
Main CI / get-go-version (push) Failing after 7s
Main CI / Build (push) Skipped
* Fix backup-finalizer: do not set backup phase to Completed before PutBackupMetadata succeeds Previously, the backup finalizer controller set backup.Status.Phase to Completed/PartiallyFailed in-memory BEFORE calling PutBackupMetadata and PutBackupContents. When these uploads failed (e.g., due to object lock or immutability), the deferred patch function still wrote the terminal phase to the Kubernetes API server, preventing the controller from retrying the upload on the next reconcile. This fix moves the phase assignment to AFTER both uploads succeed. A DeepCopy of the backup is used to encode the JSON with the final phase for object storage, while the in-memory backup object retains the Finalizing phase until uploads complete. Caveats: - CompletionTimestamp is now captured before upload but only committed to the API server after upload succeeds. On retry after a transient failure, a new timestamp is generated, so the completion time reflects when the upload finally succeeded rather than when finalization processing completed. - Metrics (RegisterBackupSuccess/RegisterBackupPartialFailure) are now recorded after uploads succeed, so they accurately reflect only fully persisted backups. - The metadata uploaded to object storage contains the final phase and completion timestamp via DeepCopy, so storage state is correct even before the API server is patched. Fixes #9645 Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com> * Add changelog for #9646 Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com> * Fix testifylint: use require.Error instead of assert.Error Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com> * Address review feedback on backup-finalizer fix - Add default guard for unhandled phase values in finalPhase switch - Add retry with DefaultBackoff for PutBackupMetadata per reviewer request - Replace brittle framework.BackupItemActionResolverV2{} mock with mock.Anything - Add FinalizingPartiallyFailed test case for PutBackupContents failure Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com> * Use bounded, object-storage-tuned backoff for backup-finalizer uploads retry.DefaultBackoff is tuned for API server optimistic-concurrency conflicts (4 steps, ~1.25s total) and gives up far too quickly for object storage calls, which can see longer transient outages or throttling (review feedback from blackpiglet). Replace it with a dedicated, bounded backoff (1s base, 2x factor, 5 steps, ~31s total) applied to both PutBackupMetadata and PutBackupContents. Being bounded (rather than retrying forever) means a persistent failure, e.g. an object-lock/immutability policy denying every write, surfaces as an error within a bounded time instead of hanging the reconcile indefinitely; controller-runtime requeues on error, so retries continue across reconciles (review feedback from priyansh17). Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com> * Fix PutBackupMetadata retry to re-read backupJSON each attempt backupJSON is a bytes.Buffer, so passing it directly to PutBackupMetadata drains it on the first read attempt. A retry after a transient failure would then upload empty content instead of the backup metadata. Wrap it in bytes.NewReader(backupJSON.Bytes()) inside the retry closure so every attempt gets a fresh reader. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com> --------- Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Happy <yesreply@happy.engineering>