Fix A, the page too: the restore's first verdict needs a stable 45 s after the 90 s health wait on every path, so an app that runs, crashes and restarts reads „not started yet”; the copy still waits the full 3 minutes. Red-proved. Commit only.

2026-10-25 13:06:06 +01:00
parent 7720439440
commit 2149a13378
10 changed files with 88 additions and 18 deletions
@@ -31,7 +31,9 @@ says „not started yet", alarms the operator; a late start is a success; never
  that read „running", and a restore whose 90 s health wait passed dropped it at once — an app crashing and restarting
  reads „running" between crashes. Now ONE rule (`waitStableStart`) for both: for 3 minutes every sample (each 10 s) has
  the stack running, every healthcheck `healthy`, the same containers and no RestartCount grown (`ContainerSamples`, a
-  read-only `docker inspect` in the stack adapter). The page's first verdict is unchanged; the copy is released after
+  read-only `docker inspect` in the stack adapter). The page's first verdict also needs a stable 45 s after the 90 s
+  health wait (`restoredAppStarted`, every restore path), so an app that runs, crashes and restarts reads „not started
+  yet" on the page as well (`TestFixA_AFlappingAppKeepsTheCopy`, seen failing with the one-sample wait); the copy is released after
  the window (`releaseAfterStableStart`), or stays for support with one operator line if no stable window comes in 30
  minutes. A NEW restore of the app (one begun after the watch started) ends the watch untouched — found while
  testing: the watch starts inside its own restore, before the page's record ends, so „a restore of the app runs"