US04-04 — Recover or Roll Back Interrupted Renames #23

New Issue

domverse · 2026-07-13T13:10:45+02:00

domverse commented

2026-07-13 13:10:45 +02:00

Source specification: delivery_backlog/stories/US04-04-rename-recovery.md

US04-04 — Recover or Roll Back Interrupted Renames

Epic: E04

As an operator, I want safe recovery choices after interruption so partially renamed
albums never trigger blind retries or data loss.

Acceptance criteria

Recovery derives action from journal plus current source/destination evidence.
Resume and rollback revalidate recorded hashes and refuse changed paths.
Ambiguous states block unrelated mutations and explain manual recovery precisely.
Recovery and rollback are idempotent across repeated restarts.

Automated tests

Fault injection terminates the process at every persisted rename transition.
Tests cover resume, rollback, changed paths, unexpected destinations, and repeated
restart with no overwrite or asset loss.

Dependencies

US04-03

Source specification: [delivery_backlog/stories/US04-04-rename-recovery.md](https://git.domverse-berlin.eu/domverse/photoanalyzer/src/branch/main/delivery_backlog/stories/US04-04-rename-recovery.md) # US04-04 — Recover or Roll Back Interrupted Renames Epic: [E04](https://git.domverse-berlin.eu/domverse/photoanalyzer/src/branch/main/delivery_backlog/E04-guarded-renaming.md) As an operator, I want safe recovery choices after interruption so partially renamed albums never trigger blind retries or data loss. ## Acceptance criteria - Recovery derives action from journal plus current source/destination evidence. - Resume and rollback revalidate recorded hashes and refuse changed paths. - Ambiguous states block unrelated mutations and explain manual recovery precisely. - Recovery and rollback are idempotent across repeated restarts. ## Automated tests - Fault injection terminates the process at every persisted rename transition. - Tests cover resume, rollback, changed paths, unexpected destinations, and repeated restart with no overwrite or asset loss. ## Dependencies - US04-03

domverse added this to the E04 — Guarded Renaming milestone 2026-07-13 13:10:45 +02:00

domverse added the priority/critical type/feature area/backend area/filesystem labels 2026-07-13 13:10:45 +02:00

domverse added a new dependency 2026-07-13 13:11:24 +02:00

#22 US04-03 — Apply and Verify Guarded Renames

domverse added a new dependency 2026-07-13 13:11:24 +02:00

#24 US04-05 — Operate Rename Plans in the Browser

domverse added a new dependency 2026-07-13 13:11:25 +02:00

#25 US04-06 — Automate Phase D End-to-End Acceptance

domverse added this to the Photo Analyzer Delivery project 2026-07-13 13:19:45 +02:00

domverse added the status/backlog label 2026-07-13 13:52:50 +02:00

domverse referenced this issue

2026-08-16 11:26:43 +02:00

US04-03: Apply and Verify Guarded Renames #68

domverse commented

2026-08-16 11:27:47 +02:00

Delivered together with US04-03 in PR #68 (merged as 7103cb8).

Apply and recovery were combined deliberately: recovery reads exactly the journal evidence that apply writes, so building apply first would have shipped filesystem mutation with no recovery path — the most dangerous intermediate state in this backlog.

US04-04 acceptance criteria, all covered in tests/integration/test_rename_recovery.py:

Recovery derives its action from the journal plus current source/destination evidence (RenameJournal.classify → resumable / rollback_safe / manual).
Resume and rollback revalidate the recorded hashes and refuse changed paths (test_rollback_refuses_content_whose_bytes_changed) and occupied sources (test_rollback_refuses_when_the_source_is_occupied).
Ambiguous states block unrelated mutations and explain manual recovery precisely (test_an_unexpected_destination_occupant_forces_manual_recovery, test_manual_work_blocks_a_different_plan_from_applying).
Recovery and rollback are idempotent across repeated restarts (test_recovery_is_idempotent_across_repeated_restarts, test_rollback_is_idempotent).
Fault injection terminates a real child process at every persisted rename transition (moving / moved / database_updated / verified) and asserts no content is lost or overwritten.

Closing as done.

Delivered together with US04-03 in PR #68 (merged as 7103cb8). Apply and recovery were combined deliberately: recovery reads exactly the journal evidence that apply writes, so building apply first would have shipped filesystem mutation with no recovery path — the most dangerous intermediate state in this backlog. US04-04 acceptance criteria, all covered in `tests/integration/test_rename_recovery.py`: - Recovery derives its action from the journal plus current source/destination evidence (`RenameJournal.classify` → resumable / rollback_safe / manual). - Resume and rollback revalidate the recorded hashes and refuse changed paths (`test_rollback_refuses_content_whose_bytes_changed`) and occupied sources (`test_rollback_refuses_when_the_source_is_occupied`). - Ambiguous states block unrelated mutations and explain manual recovery precisely (`test_an_unexpected_destination_occupant_forces_manual_recovery`, `test_manual_work_blocks_a_different_plan_from_applying`). - Recovery and rollback are idempotent across repeated restarts (`test_recovery_is_idempotent_across_repeated_restarts`, `test_rollback_is_idempotent`). - Fault injection terminates a real child process at every persisted rename transition (moving / moved / database_updated / verified) and asserts no content is lost or overwritten. Closing as done.

domverse added status/done and removed status/backlog labels 2026-08-16 11:27:48 +02:00

domverse closed this issue

2026-08-16 11:27:48 +02:00

domverse moved this to Done in Photo Analyzer Delivery on 2026-08-16 11:58:49 +02:00

Sign in to join this conversation.