Altinity / Altinity/clickhouse-backup
watch: distinguish post-upload retention failure from upload failure
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.6k
- Forks
- 276
- Avg merge
- 18h 3m
- Merged PRs (30d)
- 26
Description
Split from #1532 (point 3).
`RemoveOldBackupsRemote` runs in `upload.go` after the new backup is fully uploaded. When it fails, `CreateToRemote` returns an error and the `watch` loop treats it like a failed upload: `prevBackupName` is not advanced (next increment diffs from a stale base although the fresh backup exists on remote), `createRemoteErrCount` grows and `watch` aborts with "too many errors".
Proposal: in `watch`, when upload succeeded but retention failed, advance `prevBackupName`/`backupType` and don't count it towards abort, but still log at error level and report the error in status/callback. One-shot `create_remote` keeps the non-zero exit code.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in upload.go with RemoveOldBackupsRemote and trace how CreateToRemote reports errors to the watch loop. Follow the handling of prevBackupName, backupType, createRemoteErrCount, status, and callbacks; done means retention failures remain visible and logged, but do not behave like upload failures in watch, while create_remote still exits non-zero.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100