Marc-André Bombeck a8898bbee7 Pin that a refused restore has not already wiped the account ...

The restore refuses a portable backup, because a portable export carries
document metadata without the stored bytes and `contentEncrypted` is NOT
NULL. That refusal is deliberate and documented at the guard.

What nothing pinned is the half that makes it survivable: the check runs
above the transaction that wipes the account. The guard reads like input
validation, and input validation drifts toward wherever the value is
first used. Move it below the wipe and the operator loses everything to
a file the server was always going to reject — and the non-null
assertions further down are safe only because it stands where it does.

The test drives a real portable payload through the real route and reads
rows, not return values: the refusal happens, the account still has
every row it had, the cache invalidation never fired, and the audit row
names the document. Asserting the status alone would stay green through
exactly the edit this is here to catch, so the surviving rows are
asserted separately rather than inferred from it.

Verified by breaking it: disabling the guard turns the 422 into a 500,
which is the raw TypeError from decoding bytes that are not there.

2026-08-22 00:01:52 +02:00

..

fixtures/v137

Let a checkup be skipped or pushed back, and remember every outcome

2026-08-14 09:23:58 +02:00

integration

Pin that a refused restore has not already wiped the account

2026-08-22 00:01:52 +02:00