Skip to content

Refused restore mutates the occupied target — data loss, proven by digest #932

Description

@FerroxLabs

Found by the merge test gate on its first real cadence run (2026-07-31), at integration e64ec3da. Pre-existing — it fails identically at the merge and at base 674b72c8, deterministically, on every attempt of retries = 2.

Test: wcore-cli::portability_hostile_corpus hostile_refused_restore_leaves_an_occupied_target_byte_identical
Site: crates/wcore-cli/tests/portability_hostile_corpus.rs:1242

The test digests an occupied target before and after a restore that is refused, and the digests differ:

before 3044f265e70cc6624fd44cc39eab10299a43c6190630af49296e847530ba5018
after  d50b29ed835e66b420b75fe0fbc98713087f7ee52a8c127a8890276303d32047

So the refusal path has already written to the user's file by the time it declines. The refusal message says the right thing while the bytes do not — which is exactly why the test measures by digest rather than reading the message. Any check that trusted the refusal text would have called this correct.

Same family as #114 (restore --replace torn-SQLite on the rollback side): a path that declines after it has already mutated.

It is currently recorded in .planning/merge-test-baseline.txt as accepted debt so the merge gate keeps a reachable pass state. That is a holding position, not a disposition — the baseline entry should be removed when this is fixed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:coreWayland Core engine / backends

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions