v0.205.0 — a run that skipped an app the customer selected is not successful (R-234)
gates / gates (push) Successful in 21s
gates / gates (push) Successful in 21s
THE VERDICT. The R-203 block already said "a warning beside a success is read as a success" and applied it to ONE of the two shapes it describes: an app missing a declared mandatory FOLDER made the run incomplete, while an app skipped ENTIRELY still reported ok. Both do now. Which skips count, decided by measurement: selected+deployed with no recovery unit YES; selected but NOT deployed no (named, with what to do — a box left amber by an app somebody removed is a status nobody reads); disconnected/decommissioned drive no (own signal); nothing selected no. LastSuccess and SnapshotCount still record what WAS captured. THE FILED MECHANISM WAS NOT THE MEASURED CAUSE, and saying so is the point. §3 stated that toggling an app on leaves it without a bundle so the first run skips it. Measured on demo-hp: the run's own pre-dump phase calls captureAllRecoveryUnits for every DEPLOYED stack, through admitApp, before the push — a unit moved aside was RECREATED and the run reported ok. That state does not survive a run. What actually produced the 2026-08-06 sequence: the manual run was dropped by the single-flight while an earlier run was still going. runOffboxBackup returned nil, the handler had already answered "A tavoli mentes elindult", and the card then showed the PREVIOUS run's green verdict — read as covering the app just selected. The decision is now taken synchronously in the handler and a dropped request says so. The nightly path still returns nil on purpose: nobody asked, and it retries. §7.3 measured before deciding: CaptureRecoveryUnit writes a few KB of compose + manifest, only ENUMERATES dumps rather than creating them, is idempotent and does NOT stop the app — and already runs inside the off-site run. So there is no wait to remove for a deployed app and NOTHING was built. 28 packages ok, 9/9 gates. Four red-proofs, each asserted to have applied. Fixture note: the shared provider's ListDeployedStacks returned nil, so Scenario A first passed for the wrong reason; fixed with an opt-in deployed set that defaults to nil.
This commit is contained in:
@@ -160,6 +160,13 @@ backups, monitoring and notifications. All Proxmox/disk operations are delegated
|
||||
snapshots sat in the repository. Installed-ness is a property OF a row (it changes what restoring
|
||||
implies), never a filter on it; an unreadable store renders as UNKNOWN and keeps the action; the
|
||||
`felhom-offbox` and `_shares` marker tags are never offered as apps.
|
||||
**A run that skipped a selected app is `incomplete` (v0.205.0, R-234):** the off-site verdict now
|
||||
counts `missingUnprotected` beside `mandatoryGaps` — an app the customer selected that is DEPLOYED
|
||||
but has no recovery unit is not protected, so the run is not `ok`. A selected-but-UNDEPLOYED app is
|
||||
named with what to do and does NOT move the verdict (a permanently amber box is a status nobody
|
||||
reads); a disconnected/decommissioned drive has its own signal. The manual „Távoli mentés most”
|
||||
also refuses SYNCHRONOUSLY when a run is already in flight, instead of answering „elindult” and
|
||||
leaving the previous run's verdict on the card.
|
||||
(traefik/cloudflared/filebrowser) get curated Hungarian display identity from the
|
||||
`inframeta.go` map (name + description + generic `/static/infra-logo.svg` fallback icon);
|
||||
filebrowser is the only infra stack with a customer link (`files.<domain>`).
|
||||
|
||||
Reference in New Issue
Block a user