3 Commits

Author	SHA1	Message	Date
admin	985388c6e9	R-351: the restore compares where the backup says the data lived; second press cannot start a second run ... Part 3 (not droppable) and the engine half of Part 2. No version bump yet - one bump and one bake at the end of the session. PART 3a - a second press really did start a second run. Established with a test BEFORE any change: both offboxReconstituteHandler and offboxPlaceHandler answered "...elindult" and overwrote the first restore's op/stack. Cause: every restore handler gated on backupMgr.IsRunning() - the CONCURRENCY flag, which the restore goroutine acquires AFTER the handler returns (offbox_reconstitute.go:180, offbox_restore.go:393). Seven sites. The wizard had read the correct flag since v0.154.0 and said so in a comment; the handlers never moved. New Server.restoreOpBlocked() reads BOTH flags - the display flag covers the whole off-box restore, the concurrency flag is the only one the nightly backup holds - and the refusal now names the running app and a route. PART 3b - the page DOES refresh; the defect was the RESULT. backups_shared.html gated the terminal result on a page-local sawRunning flag, so a restore that finished before the page was opened, or inside one 3s poll, was shown to nobody. The 2026-08-21 OpenGist restore took 8.666s and no screen ever said it completed - the answer existed only in docker logs. RestoreOpStatus.LastRecent now carries the server's verdict. The 10-minute window moved to internal/backup as RestoreResultWindow and internal/web's constant is an alias: one expression, two surfaces. Also removed the wizard's self-contradiction, which said the state refreshes automatically AND that you must refresh the page. PART 2 (engine) - every recovery unit manifest has carried drive and namespace_root since schema 1, and NO non-test code read either back. The reconstitution opened the manifest and took only the coherence stamp, then resolved its destination from the live app. A restore into a different destination succeeded silently under a green message. New backup/offbox_placement.go: CheckPlacement (pure, total), PlacementMismatchMessage, recordedPlacementFromScratch. Compared before the safety dump and before the first byte. A mismatch is NAMED and refused; ackPlacementChange lets the customer proceed deliberately - a separate field from confirm=1, because one click must not carry two decisions. An UNKNOWN recording is never a mismatch: refusing on an absence would strand every pre-field unit. The not-installed refusal (R-253) now names the drive the backup recorded. RED-PROOFS, each mutation asserted applied and reverted to 0: B both guards removed (count asserted 2) -> the restore WAS seen starting with no drive attached: no error, full 3.00s run, wrote into /tmp/mutant-destination C Mismatch forced false -> the silent divergent restore returned E Known() forced true -> the fabricated empty prefill appeared D Mismatch forced true -> 8 ordinary reconstitute tests broke, proving reachability both ways Note on D: the existing fixtures write a schema-1 manifest with NO drive, so they are scenario-E shaped. The matching case is covered in the scenario table, not by them. Gates 11/11 OK. Suite 28 packages ok. Hungarian verified as hex, no BOM, no mojibake sentinels. NOT in this commit, still open: Part 2's scenario-A prefill UI, Part 1's deploy-page visibility line, Part 1's specification document, Part 4's measurement.	2026-08-21 21:04:16 +02:00
admin	78ff991f1c	v0.153.0 — R-47: the DB replay no longer races the app, on BOTH restore paths ... Closes R-47. No new agent coupling — MinAgent stays 0.90.0. The replay needs a running DB container, so both restore paths started the WHOLE stack first, giving the application a window to rebuild the very schema objects the dump was about to create. Measured live on 2026-07-19 (H4, DIAG-immich-restore-round2): immich-server rebuilt clip_index two seconds before the dump's CREATE INDEX, the replay aborted "already exists" under ON_ERROR_STOP=1, and immich reported schema drift. The data survived only because pg_dump emits COPY before CREATE INDEX. Both paths now open a DB-ONLY window: only the stack's database service(s) come up, the dump is replayed with the app still down, and the full start runs only after the replay exits 0. Fail-closed: a dump with no identifiable DB service refuses BEFORE the first mutation. Every exit from the window still does a best-effort full start, so a failed restore never leaves a box with a database and no application. New: appbackup.DBServiceNames (yaml.v3 services-map parse — never a line scan; immich's top-level volume keys are the decoy) sharing dbTypeForImage with DiscoverDatabases; stacks.Manager.StartStackServices (refuses an empty list — argument-less `up -d` is a full start); RedeployFromEnv split into PersistUnitRedeployConfig + its unchanged tail. StackDataProvider's RecreateStackFromUnit becomes RecreateStackDefinitionFromUnit — the hidden `up -d` inside the old name is what carried the defect on the local path. 19 new tests (ordering plus state-at-replay-time, zero-mutation fail-closed effects, replay-failure bring-up, parser decoys, empty-list refusal); three companion red-proofs run and reverted. 23/23 packages green. Not yet live-validated: STOP-1 supervised reconstitute, golden 0.153.0.	2026-07-20 17:01:52 +02:00
admin	062357f778	v0.148.0 — coherent snapshot pairs + an offsite restore that actually restores (R-43 + R-44) ... Closes the two findings from DIAG-immich-restore-2026-07-19. Viktor deleted 11 immich photos to test offsite restore; both runs flashed success and the photos stayed gone. Two independent defects. R-43 — no offsite path could restore a database. All three buttons were file-only: the two "visszaállítás" actions staged to a scratch folder and never touched postgres, and place-to-live merged only MISSING files. For a DB-indexed app the bytes returned and the app still could not see them. The dump was carried INTO every snapshot and could never be replayed OUT of one. New ReconstituteFromOffsite (/backup/offbox/reconstitute): safety dump → stop → files overwritten to the snapshot version → start → the snapshot's own dump replayed → health wait. Two invariants: - nothing is ever deleted (-a, no --ignore-existing, no --delete): a file created after the snapshot survives as an extra; - the undo exists before the act — the pre-restore- dump is verified ON DISK before anything is stopped, overwritten or replayed; if it cannot be taken the operation refuses with zero changes. The replay reads the SCRATCH unit: the live unit is never overwritten, so replaying from it would replay the current DB over itself and restore nothing. R-44 — a manual push shipped an unrefreshed dump (up to ~24h old). That day's predated the customer's account by four hours and probed to asset:0/user:0/ album:0 inside 52MB whose bulk was immich's shipped geodata. Every run, manual AND nightly, now refreshes dumps + units BEFORE capturing. Order is the mechanism: the gap can only ADD files the DB does not reference yet, never remove one it does. Manifests carry offsite_run_id + dumps_at, so coherence is verifiable at restore time rather than assumed; the periodic refresh carries a prior stamp forward and never invents one. Honesty surfaces, all warn-level and none a gate: unstamped (pre-v0.148) pairs report their skew, ValidateDump gained an EXACT-match accounts-table sniff for customer-empty dumps, the completion flash states an outcome instead of a mechanism, and the missing-only button now says what it does NOT do. 11 tests; 5 red-proofs run and reverted. Two of those found real test weaknesses rather than confirming strength — the first undo mutation was caught by a second guard, and the first table-matching test did not discriminate between the two matchers at all. Both tests were rewritten to the cases that separate them. NOT in scope: R-41's catalog invariant check, nightly cadence, retention, quota math, tier-2, and v0.147.x progress semantics beyond one added phase line. Live acceptance (§9) has NOT run: no capability-map flip, customer-restore row stays MISSING, R-3 stays DRAFT. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P9Nn14TWGzKoqAJAiVwC2s	2026-07-19 12:21:16 +02:00