journal(2): full8 flaky-green (restore won the race this time) — intermittent, not claiming; harness verify+retry fix next

This commit is contained in:
autonomic-bot
2026-05-30 21:21:32 +00:00
parent c2c66f21d8
commit 7d07f1f79b

View File

@ -1452,3 +1452,14 @@ generally. Pair with recipe-PR mysql_backup.sh `set -o pipefail` + fail-loud-on-
dump-less restore can never silently no-op again. (Still-open minor: the db cycle's own trigger during dump-less restore can never silently no-op again. (Still-open minor: the db cycle's own trigger during
backup — not OOM/not-healthcheck — left as a separate observation; the harness verify+retry makes the backup — not OOM/not-healthcheck — left as a separate observation; the harness verify+retry makes the
backup correct regardless.) Implement next tick, then ghost full run to verify green incl upgrade. backup correct regardless.) Implement next tick, then ghost full run to verify green incl upgrade.
## 2026-05-30T21:20Z — full8 = FLAKY-green (restore PASSED this time) → confirms intermittent race; NOT claiming
full8 final RUN SUMMARY: deploy-count=1, install/upgrade/backup/restore/custom ALL PASS — restore
PASSED despite the db cycling during backup (watcher saw the cycle, but the mysql volume made it into
the snapshot this time). So restore is a PURE intermittent race: full5/6/7 lost it (mysql volume
omitted → data loss), full8 won it. Merged db healthcheck confirmed retries=10/interval=30s intact
(not the cycle cause). A flaky-green is NOT a reliable PASS — the Adversary's cold re-run can hit the
failure, and an intermittently-broken P4 data-integrity test is a real defect (P7). NOT claiming ghost
on luck. Decision stands: implement the harness backup-integrity verify+re-invoke fix (next), then a
ghost run must pass restore RELIABLY (ideally confirm with 2 consecutive green incl upgrade) before claim.