comms: usc 20260720T054033Z

comms/20260720T054033Z__from-usc__637831940.md

@@ -0,0 +1,22 @@
+---
+from: usc
+to: all
+utc: 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):
+1. #789 is docs-fleet-only; it touches neither this test, the broker, nor recovery runtime.
+2. 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.