test(daemon): bound idle frontend maintenance probes - #2215

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Thank you for the eviction regression. The test's fixed 100 ms sleep is shorter than the current 250 ms production idle interval, so elapsed sleep is not a deterministic proof that eviction reached the intended state. Please make the test control or observe the relevant state transition rather than increasing the sleep budget or adding retries.

Thank you — bounding idle frontend maintenance probes is a good guard to have, and 21 lines in one test file is an easy review.

One blocker, and it is the only thing standing between this and a merge: the dco check.

Your commit carries no Signed-off-by trailer — the message is a headline with an empty body, so there is nothing for the check to parse. (It is not the blank-line trap, where a sign-off sits outside the trailer block and git's parser ignores it while grep still sees it. Here there is genuinely no trailer.)

git commit --amend -s
git push --force-with-lease

Every other check on this PR is green (31 success, 1 skipped). Sign it off and I will merge it.

A note on how I will review it once it is green, since it is a test-only change: I check that a new test can actually fail, by reverting the production code it covers and confirming the test goes red. A test that passes with the behaviour removed proves nothing, and this repository has shipped a few of those. For a pure guard like this one, the question I will be asking is whether an unbounded probe loop would actually trip it — if you already know it does, saying so in a sentence saves me the round trip.

For what it is worth: #2241 and #2242 were signed off correctly and both merged today after exactly that check. Nice work on those.

Thanks again for the idle-probe guard. The thread contains both a determinism concern and a later sign-off request; the next review needs to reconcile those and confirm the guard detects the old behavior. Please retain that regression intent when updating the sign-off.

Thanks again for the idle-probe regression. We still owe a clear reconciliation of the determinism concern and the later sign-off request; the test should retain its ability to detect the old behavior. Sorry for the delay on that review—I’ll follow up soon.

Thanks for sticking with this, @lorenzozanee, and sorry it took us so long to reconcile our two earlier notes. Guarding the idle maintenance cadence is worth having: nothing on main pins it today, and your test does catch the old 10 ms hot loop.

1. Sign-off - the one step only you can take. The commit has no Signed-off-by trailer, so the dco check stays red, and we cannot sign off on your behalf. Please run:

   git commit --amend -s
   git push --force-with-lease

2. Determinism - we will take this part. The fixed 100 ms sleep decides the result: on a slow runner the monitor may not have probed yet, or the sleep may overrun the 250 ms cadence. Once your signed commit is up, we will add a commit on your branch that records the idle interval the monitor actually requests and asserts on that, so timing no longer matters. Reverting to the 10 ms cadence still turns it red, so your regression intent stays.

Then we merge current main in and merge on green. Thank you!

Thank you, @lorenzozanee, for the idle-cadence guard. You were right that nothing on main pinned the quiet-session probe interval, and your test caught the old 10 ms hot loop that #2093 describes. That regression intent is exactly what we kept.

As we said in our last note, we made the result independent of timing: in test builds the monitor now records the idle interval it actually requests, and the test asserts on that value instead of counting probes inside a fixed 100 ms sleep. Switching the monitor back to the 10 ms cadence still turns it red. Because this branch's commit has no DCO sign-off, which only you can add, we landed the result in #2951 (merge f5d5746), with you credited as co-author on the commit.

Closing this one in favor of #2951. Thank you for sticking with it.