From 7d07f1f79b290e3735511f82da63dd1846262a15 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Sat, 30 May 2026 21:21:32 +0000 Subject: [PATCH] =?UTF-8?q?journal(2):=20full8=20flaky-green=20(restore=20?= =?UTF-8?q?won=20the=20race=20this=20time)=20=E2=80=94=20intermittent,=20n?= =?UTF-8?q?ot=20claiming;=20harness=20verify+retry=20fix=20next?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- machine-docs/JOURNAL-2.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/machine-docs/JOURNAL-2.md b/machine-docs/JOURNAL-2.md index 63d7a28..61d76df 100644 --- a/machine-docs/JOURNAL-2.md +++ b/machine-docs/JOURNAL-2.md @@ -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 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. + +## 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.