Repository navigation
test(daemon): pin the idle maintenance-probe cadence - #2951
Merged
Merged
Conversation
The frontend maintenance monitor probes for a maintenance request on every cycle, and each probe try-acquires the maintenance marker lock (on Windows that revalidates the whole ancestor directory chain). The quiet no-maintenance cadence was raised from 10 ms to 250 ms because the 10 ms loop burned a large share of a core for the life of every MCP session, but nothing pinned that cadence: a regression back to the hot loop would pass every suite. The monitor now sleeps on a local idle_ms in its ABSENT branch and, under CBM_ENABLE_TEST_SEAMS only, records that exact value immediately before sleeping on it (cleared by cbm_daemon_frontend_test_observer_reset). The new test starts an idle monitor, waits until a value is recorded, stops the monitor and asserts the recorded sleep is at least 250 ms. Once set, the recorded value is stable, so the verdict depends on neither elapsed time nor scheduler cadence; the deadline is only a hang guard. Production builds carry no seam code and sleep the same 250 ms as before. The original test counted presence observations inside a 100 ms window, which asserts a transient timing window; it is replaced by the recorded cadence above. Refs #2093 Distilled from #2215. Co-authored-by: lorenzozanee <[email protected]> Signed-off-by: Martin Vogel <[email protected]>
This was referenced Nov 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this guards
The frontend maintenance monitor probes for a maintenance request on every cycle,
and each probe try-acquires the maintenance marker lock (on Windows this
revalidates the whole ancestor directory chain). The quiet no-maintenance cadence
was raised from 10 ms to 250 ms because the hot loop burned a large share of a core
for the whole life of every MCP session (#2093). Nothing pinned that cadence, so a
regression back to the hot loop would have passed every suite. This adds that guard.
Change
src/daemon/frontend.c: the monitor's no-maintenance (ABSENT) branch now sleepson a local
idle_ms(stillFRONTEND_MAINTENANCE_IDLE_POLL_MS, 250 ms). In testbuilds only (
CBM_ENABLE_TEST_SEAMS) it records that exact value immediatelybefore sleeping on it;
cbm_daemon_frontend_test_observer_resetclears it.Production builds contain no seam code and behave exactly as before.
src/daemon/frontend.h: test-seam accessorcbm_daemon_frontend_test_monitor_idle_sleep_ms().tests/test_daemon_frontend.c:daemon_frontend_idle_maintenance_probe_is_boundedstarts an idle monitor, waits until a sleep value has been recorded, stops the
monitor, and asserts the recorded sleep is at least 250 ms.
Hardening versus the original test
The original test counted presence probes inside a 100 ms window and required
exactly one. That asserts a transient timing window: its verdict depends on
scheduler timing, and a cadence anywhere above 100 ms passes it. The reworked test
reads the value the monitor actually sleeps on. Once recorded, that value is stable,
so the verdict depends on neither elapsed time nor scheduler cadence; the deadline
in the wait loop is only a hang guard.
How it was verified
build/c/test-runner daemon_frontend(ASan/UBSan test build, macOS arm64):18 passed, 0 failed; the new test passes.
idle_msback to the 10 msFRONTEND_MAINTENANCE_POLL_MSturns exactly the new test red (
idle_sleep_ms (10) not >= 250, 17 passed,1 failed); restoring the 250 ms cadence returns the suite to green.
src/daemon/frontend.calso compiles cleanly with production flags (seams off,-Wall -Wextra -Werror). clang-format (LLVM) is clean on every touched hunk,the memory-core linter passes, and there is no NOLINT.
Distilled from #2215 by @lorenzozanee (Co-authored-by on the commit); the original could not merge because its commit has no DCO sign-off, which only the author can add. Thank you for spotting that this cadence needed a guard!
Refs #2093