note(redfix-M2): mumble component VERIFIED (2/6) — handshake PASS 10.3s (flake confirmed, fix non-weakening); consume inbox (b96b8a4 staleness is bluesky-only, keycloak/mumble unaffected)
Some checks failed
continuous-integration/drone/push Build is failing

This commit is contained in:
autonomic-bot
2026-06-18 06:13:34 +00:00
parent 983b0392cc
commit 6ff71f76b3
2 changed files with 18 additions and 29 deletions

View File

@ -182,3 +182,21 @@ test-disabling.
before/during/after. The data-warm canonical (warm-canon-keycloak) and live-warm provider
(warm-keycloak) are fully separate deployments that never touched. Builder's keycloak fix CORRECT +
non-weakening; the §2.B de-enrollment is now structurally resolved. (1/6)
- 2026-06-18T06:15Z — **mumble component VERIFIED (2/6)** by my OWN cold harness run
(`/tmp/adv-mumble-m2.log`, RECIPE=mumble from /tmp/adv-m2, recipe tag 1.0.0+v1.6.870-0). RUN SUMMARY:
deploy-count=1, **all 5 cold tiers pass**. The stabilized custom test
`test_handshake_completes_with_channel_presence` **PASSED** (junit failures=0, time=10.3s). The
handshake completing in ~10s confirms M1's **load/timing-FLAKE** classification (fast in isolation,
nowhere near even the OLD 60s budget) and that the fix — widening 12->36 attempts (60s->180s) — is
pure headroom: the asserts are UNCHANGED, so a genuinely dead server still exhausts all 36 retries
and FAILs. **Non-weakening.** WC5 promote: `/var/lib/ci-warm/mumble/canonical.json` version
1.0.0+v1.6.870-0, idle, ts 20260618T061114Z (THIS run). Builder's mumble fix CORRECT. (2/6)
NOTE on branch state: I cloned /tmp/adv-m2 at tip `b96b8a4` just before the Builder force-reset
`redfix-m2-harness` to `07fc6d4` (dropping a bluesky exec-into-pds commit). Confirmed
`git diff 07fc6d4 b96b8a4` = ONLY `tests/bluesky-pds/_p4.py` + `test_account_and_post.py` (2 lines,
bluesky-only) → keycloak (61211db) and mumble (07fc6d4) code are BYTE-IDENTICAL between b96b8a4 and
the claimed tip 07fc6d4, so my keycloak+mumble PASSES hold at the claimed state. bluesky is verified
separately via recipe chaos-deploy (PR #4 @4987ba9, now recipe-PR-only per operator directive), so
the harness-checkout staleness does not touch it.