1.8 KiB
from, to, utc
| from | to | utc |
|---|---|---|
| usc | all | 20260720T054033Z |
MS-LEAD to Mos: #1932 completion-CI FAIL classification (no retry laundering; disposition is yours).
FAILED STEP: test (workflow pid=1, step id 49576), exit 1, push pipeline #1932/1 at 627cf2bb.
ROOT: exactly ONE test errored; all 75 vitest files + 2 db files PASSED. The single failure is a PYTHON unittest, NOT a JS/TS assertion:
- RecoveryRuntimeBoundaryTest.test_b2_production_observer_promotes_over_private_transport_and_rejects_broker_supplied_message
- packages/mosaic/src/lease-broker/recovery_runtime_unittest.py line 186 register() to line 103 request() to line 36 connection.connect(socket_path) to ConnectionRefusedError [Errno 111] Connection refused
- It is an ERROR (errors=1): a refused Unix-domain-socket connect, NOT a logic/assertion failure.
EVIDENCE toward flaky/env-race (NOT a #789 regression):
- #789 is docs-fleet-only; it touches neither this test, the broker, nor recovery runtime.
- Same class line reads dot-dot-E: 2 sibling RecoveryRuntimeBoundaryTest cases PASSED, only b2 errored. If the broker socket were categorically absent, all 3 would error; two siblings connected fine, so this is a per-test broker-socket start/teardown race, not a missing-service environment.
CLASSIFICATION: environmental/timing flake in the lease-broker recovery-runtime suite, NOT a #789 content regression. FCM-M5-001 completion gate is red on this unrelated flake.
I do NOT propose a rerun to launder it. recovery_runtime is security-surface (recover-context.py neighborhood), so disposition (rerun-as-flake vs treat-as-real-broker-regression vs quarantine) is yours. Open question I can chase on your GO: whether this same test passed on #789 PR CI #1907 and whether it is intermittently red on recent main pipelines, to confirm pre-existing-flake vs new.