From 76438226067e9a91437491886cafdfbfa4a32c18 Mon Sep 17 00:00:00 2001 From: Swung0x48 Date: Tue, 6 Oct 2026 05:23:59 -0400 Subject: [PATCH] [Docs] (CI): log the spawn, FencePoll and log-forward flake fixes --- docs/ci/ci-cleanup-log.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/ci/ci-cleanup-log.md b/docs/ci/ci-cleanup-log.md index cf9cf33a..9faf8686 100644 --- a/docs/ci/ci-cleanup-log.md +++ b/docs/ci/ci-cleanup-log.md @@ -83,3 +83,7 @@ them wrong. |---|---|---|---| | 2026-10-06 | every `ctest` invocation in integration / verify / split jobs exited 8 after the tests passed (`integration-verify`, `integration-split*`, `integration (inproc)`, `spawn_lane_parity.py`) | `PipeCatalogueSourceRoot.cmake` (a CTest include file) used `if(... IN_LIST ...)`; CTest scripts run without policy CMP0057 on the pinned CMake 3.31.10, so the include errored | use `list(FIND)` instead (`MobileGL/MG_Test/Pipe/CMakeLists.txt`) | | 2026-10-06 | `TcpServer.Start.P8aUnlocatedIoBlocks` failed in 0.07 s on `integration (monolith)` | the loopback TCP endpoints (40613, knob lanes 41613-41617) sat inside Linux's ephemeral port range; with thousands of loopback client connections in the lane, an outgoing socket can own the port the supervisor binds | default endpoint moved to 30613 (knob lanes 31613-31617), below 32768 | +| 2026-10-06 | spawn lanes on hosted runners: `no Welcome within 5000 ms` | a cold `eglInitialize` on the hosted software stack took ~7 s, longer than the spawn handshake's Welcome wait | the Welcome wait takes `max(5000, MOBILEGL_IPC_COLD_START_MS)` (`ClientSession.cpp ColdHandshakeBudgetMs`); the initial-caps wait stays 5000 ms, which `InitialCapsStartup` pins | +| 2026-10-06 | `FencePollScenario` on `integration-verify-split` | the test took its `before` counter snapshot after `glFenceSync`, racing the apply thread that answers the fence | snapshot taken before the work and the fence are queued (test bug, not a product bug) | +| 2026-10-06 | `LogForwardChannel.APeerThatStopsReadingCostsWarnLinesNotTheCallersTime` on `integration-split-strict` (run 37433779649) | test race: when the channel's sender thread started late it dequeued its first line after the 16 KiB queue had already filled, so the lossy class recovered mid-flood and closed a first gap (4 drops) with its own notice - two notices, 1880 named vs 1884 counted. The channel did what its contract says (one notice per gap) | the test parks the sender in its held write (`WaitForAttempt`) before the flood, so the flood makes exactly one gap; 100/100 local runs green | +| 2026-10-06 | `TcpLane.EventForfeitPeer` (`EventForfeitPeer.StreamLogFloodWhileControlIsNotReadHoldsNoApplyThreadAndLosesNoError`) on `integration-split` (run 37433779649) | `notices <= 8` was one machine's measurement: every time the socket takes another burst during the flood, the WARN class recovers and its gap closes with a notice; the loaded runner made 14. Every other F2 assertion held (drops named exactly, no ERROR lost, no forward held its thread) | the bound is now `kFloodRecords / 10` (40), still an order of magnitude below the regression it guards (373, one notice per ERROR line) |