agent picked the oldest Velero backup instead of the newest when listing was unsorted and restored stale data
Sort before you select, and select by completion time: the agent restored stale data because the listing order was arbitrary and it took the first entry. Use when an agent choosing a Velero backup for an automated restore. Not for a restore that intentionally needs an older point, such as before a corruption event, where the fix is making that intent an explicit input.
TL;DR
Sort before you select, and select by completion time: the agent restored stale data because the listing order was arbitrary and it took the first entry. Fetch the backups for the target, filter to completed ones, sort by completion timestamp descending, and log the chosen backup's name and time in the restore record so the choice can be audited. Any restore whose target time matters should state the intended point and verify the chosen backup is the closest completed one at or before it.
agent picked the oldest Velero backup instead of the newest when listing was unsorted and restored stale dataUse this when
- The job or restore fails with this symptom: agent picked the oldest Velero backup instead of the newest when the listing was unsorted and restored stale data.
- You are working on an agent choosing a Velero backup for an automated restore and the failure repeats on the same target or schedule.
- You need the failing job, stage, or component isolated before changing retention or infrastructure.
Not for this skill when
- A restore that intentionally needs an older point, such as before a corruption event, where the fix is making that intent an explicit input.
- The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.
Steps
- Reproduce the selection: fetch the same listing the agent used and note its order and the entry the agent took. Verify: the wrong-selection mechanism is confirmed
- Rewrite selection to filter by completed status and sort by completion time, taking the newest match for the target. Verify: selection is deterministic and time-based
- Log the chosen backup's name, completion time, and the intended restore point in the run record. Verify: the choice is auditable after the fact
- Re-run the selection in a dry mode against the listing and confirm it now picks the newest completed backup. Verify: the dry run selects correctly
Variant phrasings
agent picked oldest velero backup unsorted listing restored stale
The verbatim phrasing.
agent restore selection newest backup sort completion time fix
The sorting phrasing.
velero restore agent wrong backup first entry listing order
The first-entry phrasing.
Compatibility: Agent restore selection logic over Velero backup listings
Why it happens
API listings make no ordering promise, so first-entry selection is a coin flip weighted by however the server stores objects. Restore selection is a correctness-critical decision wearing a trivial line of code, and only explicit filtering and sorting make it one.
Edge cases / pitfalls
- Partially failed backups can carry recent timestamps; the completed-status filter is as important as the sort.
- For point-in-time intent, closest-before the target beats newest overall; encode the intent in the selection inputs.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_OlaYCsv3WxEFHGT-l2Gm5g