From ff77005cc38a23aa6a78562a08332d9082818d30 Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Fri, 4 Sep 2026 16:22:40 +0700 Subject: [PATCH] Features: the deferred key set proves its own reporting coverage (fleetd #337) --- 11-Features.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/11-Features.md b/11-Features.md index 172c899..fc2155b 100644 --- a/11-Features.md +++ b/11-Features.md @@ -4281,3 +4281,31 @@ Measured on merge: replacing the `.filter(...::add)` with one that logs every na left all 1358 tests green — the noise control was correct and nothing held it there. Two tests now cover both duties, including the **reverse** policy order (allow-list first, then deny-by-default), because a guard fixed in one direction is not automatically fixed in the other. + +--- + +## The deferred key set now proves its own reporting coverage too + +**What it does.** `ConfigRefTopLevelReportingCoverageTest` covered `COLD_KEYS` and `SPLIT_KEYS` only. +It now covers the deferred bucket as well. The deferred set moved out of the test and into +`ConfigRef.DEFERRED_KEYS` (package-private, 11 keys), and `changedDeferredKeys` became +package-private like `changedColdKeys` and `changedSplitKeys`, so the test calls the real method +instead of a copy of the list. A name in any of the three sets with no comparison behind it now +fails the build, by name. + +**On.** Always on — a unit test (fleetd #337). + +**Why it exists.** The deferred bucket is the largest of the four: 11 of the 22 top-level keys. It +was also the one bucket where a name could be added with no code behind it and every checker stayed +green. Measured before the fix: dropping `guard`'s comparison out of `changedDeferredKeys` while +`"guard"` stayed in the set left all 1355 tests green. An operator who changes such a key gets no +"restart needed" line, so the daemon keeps running config that matches no file on disk and says +nothing. + +**One thing to know for maintenance.** The real number of uncovered keys was **6 of 11** — `guard`, +`worktreeRoot`, `spawnReadyTimeoutMs`, `spawnReadyPollMs`, `quarantineCooldownSeconds` and +`leadHeartbeat`. My own ticket listed a different six. The worker re-derived the list by mutating +each key one at a time, as the brief asked, and contradicted me on two entries: `lifecycle` was +already covered, and `worktreeRoot` was uncovered and missing from my list. Both corrections were +checked again on merge with a third mutation. **A list in a ticket is a starting point, not a +measurement** — re-derive it, and say so when it disagrees.