fleetd #663: remove LeadContextGauge.read 3-arg overload #665

2026-10-03T19:26:32+02:00

agent commented

2026-10-03 19:26:32 +02:00

Closes #663.

Removes LeadContextGauge.read(String configDir, String sessionId, String agentType) — the
3-arg overload that delegated to the 4-arg form with a null window, silently restoring the
fixed HIGH_THRESHOLD_TOKENS = 200_000 fallback that #637 moved away from.

Measurement (re-run on current `main`, not trusted from the issue)

Production callers of the 3-arg form: zero (confirmed again).

Test call sites of the 3-arg form: 15, not the 11 recorded in the issue (10 in
LeadContextGaugeTest.java + 1 in LeadContextGaugeHighThresholdTest.java). The issue's own
"10" count undercounts by 4 — my first grep attempt reproduced that same "10" by accident,
because \.read\([^()]*\) silently drops any call whose args contain nested parens (e.g.
tmp.toString()), which is exactly the shape of 4 of the real call sites. Counting
grep -c '\.read(' and eyeballing every line in both files gives the true count: 14 in
LeadContextGaugeTest.java, 1 in LeadContextGaugeHighThresholdTest.java.

All 15 sites are migrated to the 4-arg form.

The trap

In LeadContextGaugeHighThresholdTest.noEffectiveWindowFallsBackToTheFixed200000Default, the
3-arg call is the thing under test ("the 3-arg read() ... must behave exactly like passing a
null window"). Passed null explicitly there and left the assertion untouched. All other 14
sites are generic property tests where the window is irrelevant; null is filler there.

Also merged the 3-arg method's @param javadoc (configDir/sessionId/agentType) into the
surviving 4-arg method's javadoc, since removing the overload would otherwise have left the
public method's contract undocumented for three of its four parameters.

Verification

grep -n "read(String configDir, String sessionId, String agentType)" LeadContextGauge.java
→ empty.
grep -n "read(String configDir, String sessionId, String agentType, Long effectiveWindowTokens)" LeadContextGauge.java
→ still matches (positive control).
cd fleetd && mvn -o clean install → Tests run: 1923, Failures: 0, Errors: 0, Skipped: 0,
BUILD SUCCESS. Test count unchanged at 1923 (no tests added or removed).
Mutated HIGH_THRESHOLD_TOKENS to 200_000 * 2, ran
LeadContextGaugeHighThresholdTest → red:
the fixed default must still be 200,000 when no window is resolvable ==> expected: <HIGH> but was: <OK>
(failed at an earlier assertion in the same test method than the migrated line, since JUnit
stops at the first failing assertEquals — all three assertions in that method depend on the
same fallback). Reverted from a pre-mutation backup and touched the source so the next build
recompiles instead of reusing the stale mutated class; diff against the backup is empty.

Closes #663. Removes `LeadContextGauge.read(String configDir, String sessionId, String agentType)` — the 3-arg overload that delegated to the 4-arg form with a `null` window, silently restoring the fixed `HIGH_THRESHOLD_TOKENS = 200_000` fallback that #637 moved away from. ## Measurement (re-run on current `main`, not trusted from the issue) Production callers of the 3-arg form: zero (confirmed again). Test call sites of the 3-arg form: **15**, not the 11 recorded in the issue (10 in `LeadContextGaugeTest.java` + 1 in `LeadContextGaugeHighThresholdTest.java`). The issue's own "10" count undercounts by 4 — my first grep attempt reproduced that same "10" by accident, because `\.read\([^()]*\)` silently drops any call whose args contain nested parens (e.g. `tmp.toString()`), which is exactly the shape of 4 of the real call sites. Counting `grep -c '\.read('` and eyeballing every line in both files gives the true count: **14** in `LeadContextGaugeTest.java`, **1** in `LeadContextGaugeHighThresholdTest.java`. All 15 sites are migrated to the 4-arg form. ## The trap In `LeadContextGaugeHighThresholdTest.noEffectiveWindowFallsBackToTheFixed200000Default`, the 3-arg call is the thing under test ("the 3-arg read() ... must behave exactly like passing a null window"). Passed `null` explicitly there and left the assertion untouched. All other 14 sites are generic property tests where the window is irrelevant; `null` is filler there. Also merged the 3-arg method's `@param` javadoc (configDir/sessionId/agentType) into the surviving 4-arg method's javadoc, since removing the overload would otherwise have left the public method's contract undocumented for three of its four parameters. ## Verification - `grep -n "read(String configDir, String sessionId, String agentType)" LeadContextGauge.java` → empty. - `grep -n "read(String configDir, String sessionId, String agentType, Long effectiveWindowTokens)" LeadContextGauge.java` → still matches (positive control). - `cd fleetd && mvn -o clean install` → `Tests run: 1923, Failures: 0, Errors: 0, Skipped: 0`, `BUILD SUCCESS`. Test count unchanged at 1923 (no tests added or removed). - Mutated `HIGH_THRESHOLD_TOKENS` to `200_000 * 2`, ran `LeadContextGaugeHighThresholdTest` → red: `the fixed default must still be 200,000 when no window is resolvable ==> expected: <HIGH> but was: <OK>` (failed at an earlier assertion in the same test method than the migrated line, since JUnit stops at the first failing `assertEquals` — all three assertions in that method depend on the same fallback). Reverted from a pre-mutation backup and `touch`ed the source so the next build recompiles instead of reusing the stale mutated class; `diff` against the backup is empty.

agent added 1 commit 2026-10-03 19:26:33 +02:00

fleetd #663 : remove LeadContextGauge.read's 3-arg overload

CI / shell-tests (pull_request) Failing after 7s

Details

CI / contract (pull_request) Successful in 58s

Details

CI / build (pull_request) Failing after 1m34s

Details

a52ca35d34

The 3-arg read(configDir, sessionId, agentType) delegated to the 4-arg
form with a null window, silently restoring the fixed 200_000 fallback
that #637 moved away from. It had zero production callers; both
production call sites already use the 4-arg form.

Migrate all test call sites to the 4-arg form. For the generic property
tests in LeadContextGaugeTest, the window is irrelevant and null is
filler. In LeadContextGaugeHighThresholdTest's
noEffectiveWindowFallsBackToTheFixed200000Default, null is the
meaningful value under test, not filler; the assertion is unchanged.

ltms referenced this pull request

2026-10-03 19:31:06 +02:00

Remove LeadContextGauge.read's 3-arg overload — the last back-compat form that silently restores the fixed 200000 threshold #663

agent added 1 commit 2026-10-03 19:34:50 +02:00

fleetd #663 : remove the dead legacy assertion review flagged on PR 665

CI / shell-tests (pull_request) Failing after 9s

Details

CI / contract (pull_request) Successful in 57s

Details

CI / build (pull_request) Failing after 2m6s

Details

60fa86a107

noEffectiveWindowFallsBackToTheFixed200000Default's third assertion
(legacyConfigDir/legacyGauge) used to call the 3-arg read() to prove
it behaved like a null window. With the 3-arg form gone, it is the
same call, same input (200_000) and same expectation as the atGauge
assertion above it, so it cannot fail unless that one already failed,
and its message named a method that no longer exists. Deleted it; the
first two assertions (199_999 -> OK, 200_000 -> HIGH) are unchanged.

ltms referenced this issue from a commit

2026-10-03 19:38:30 +02:00

Merge PR #665: fleetd #663 — remove LeadContextGauge.read's 3-arg overload

ltms referenced this pull request

2026-10-03 19:38:48 +02:00

Remove LeadContextGauge.read's 3-arg overload — the last back-compat form that silently restores the fixed 200000 threshold #663

ltms closed this pull request

2026-10-03 19:38:55 +02:00