You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: design/backup_cancellation.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,6 +46,23 @@
46
46
- The existing `backup_finalizer_controller` will handle cancelled backups by cleaning up backup data while preserving logs, then transitioning to `BackupPhaseFailed`
47
47
48
48
49
+
- Extend the backup request struct to include:
50
+
-`Cancel` (bool): reflects whether cancellation has been requested.
51
+
-`LastCancelCheck` (timestamp): records the last time cancellation status was checked.
52
+
53
+
- Cancellation check logic:
54
+
1. If `LastCancelCheck` is zero, set it to the current time and continue as usual.
55
+
2. If more than a configured interval (e.g., 1–3 seconds) has passed since `LastCancelCheck`:
56
+
- Update `LastCancelCheck` to now.
57
+
- Retrieve the latest backup object from the API.
58
+
- Set `request.Cancel` to the current value of `backup.Spec.Cancel`.
59
+
3. Always use the current value of `request.Cancel` to determine if cancellation is requested.
60
+
61
+
- If backup processing is concurrent (multi-threaded), protect access to `request.Cancel` and `LastCancelCheck` with read/write mutexes to avoid race conditions.
0 commit comments