recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
autonomic-bot
2026-05-30 21:21:32 +00:00
parent c2c66f21d8
commit 7d07f1f79b
1 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
machine-docs/JOURNAL-2.md
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
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.