T-YON4-backup-prune-tests

State: planning/draft · Impact: medium · Complexity: small

Goal

Pruning deletes history for good. It needs regression cases at the contract level and a journey through the real UI, so a later change cannot quietly break kept snapshots or drop too much.

Today

The backup contract cases live in crates/determined-parity/fixtures/cases/backup/ and replay through crates/determined-backup/tests/cases.rs. The runner pins one commit date, 2026-01-01T00:00:00+00:00, for every history step, so all snapshots in a case share a date and a date cutoff cannot split them. A case runs its history and edits setup, then makes exactly one call; the op dispatch has no prune arm. The Playwright suite in solutions/determined/tests/ui/backup/ boots a platform-server over a scratch vault and store (harness.ts) and covers back up, browse, restore and Undo.

Proposed

• The case runner accepts an optional date on each history step and uses it for that commit. Steps without one keep the pinned date, so existing cases and their shas do not change.
• A new setup key, prune: { keep_since }, runs a prune after history and before edits and the call. keep_since is an absolute date, since commit dates are pinned. @N still names history step N’s sha, which a prune does not change.
• A prune arm in the op dispatch, for cases whose call is the prune itself.
• New cases under fixtures/cases/backup/:
  • prune-keeps-recent (call: prune): dated history; the snapshots at or after keep_since and the newest one before it are kept with the same shas, and older ones are gone.
  • prune-drops-deleted-content (call: prune): a large file deleted before the boundary is no longer readable at any kept snapshot, and bytes-after is smaller.
  • prune-cutoff-after-newest (call: prune): keeps exactly the newest snapshot.
  • prune-nothing-older (call: prune): no snapshot is older than keep_since; the prune is a no-op.
  • get-changes-boundary (setup prune, call: get_changes): the boundary snapshot is marked as the oldest kept.
  • restore-file-from-boundary (setup prune, call: restore_file): a note deleted after the boundary is restored as it was at the boundary.
  • run-snapshot-after-prune (setup prune, call: run_snapshot): a snapshot after a prune commits on top of the kept head.
• An e2e journey: the harness seeds the store with back-dated snapshots before the server starts. The spec turns on retention, opens the preview, confirms “Prune now”, and checks the list, the boundary label, the store size readout, and that a pruned snapshot’s link shows the “may have been removed by retention” message.

Approach

1. Add the per-step date, the prune setup key and the prune op arm to tests/cases.rs, and document them in the file’s header.
2. Write the cases and bless their expected.json with PARITY_BLESS=1; review and unstamp them.
3. Add store seeding with dated commits to the e2e harness.
4. Add the prune spec.

Areas

Area	Note
solutions/determined/crates/determined-backup/tests/cases.rs	Per-step commit date, prune setup key, prune op arm
solutions/determined/crates/determined-parity/fixtures/cases/backup/	New prune cases
solutions/determined/tests/ui/backup/	Dated store seeding and a prune spec

Acceptance criteria

• AC-1: All existing backup cases pass unchanged with the per-step date in place.
• AC-2: The seven prune cases pass.
• AC-3: The e2e prune journey passes locally and leaves nothing outside its temp directories.

Out of scope

• Testing the scheduled prune’s timing; T-94OR’s unit tests cover when it runs.

Dependencies

• T-A97O: the prune operation.
• T-94OR: the settings UI the e2e journey drives.

Depends on

T-A97O-backup-prune-operation, T-94OR-backup-retention-setting

---

← Back to Tasks