fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

#269 follow-up: the "allowed N of M" INFO line still claims to describe the member's pane #276

New Issue
Closed
opened 2026-09-04 05:00:37 +02:00 by ltms · 0 comments
ltms commented 2026-09-04 05:00:37 +02:00
Owner
Copy Link
Copy Source

Found by a bug-hunt fan-out, verified in the code. This is a gap in my own #269 fix.

#269 stopped four sites in HerdrPeerLauncher from asserting things about the member's environment that fleetd cannot see when memberHerdrSocket is configured. The WARN in logCredentialGap got a memberHerdrSocketConfigured() guard.

The INFO line beside it did not. logAllowListCoverage is called unconditionally two lines earlier:

logAllowListCoverage(allowed);      // no guard
logCredentialGap(creds, allowed);   // guarded since #269

and it reads fleetd's own environment:

Set<String> hostNames = hostEnvNames.get();
long kept = hostNames.stream().filter(name -> MemberEnvAllowList.keeps(allowed, name)).count();
log.info("member credentials: allowed {} of {}", kept, hostNames.size());

Read plainly, member credentials: allowed 7 of 39 is a statement about the member's credentials. Under memberHerdrSocket the pane is routed to a second herdr whose environment fleetd has no channel to inspect, so the counts describe fleetd's own process instead. Same overclaim #269 existed to remove, in the line next door.

The method's javadoc does carry the caveat, via a cross-reference to another field's javadoc. That does not help: the operator reading fleetd.out never sees it.

Fixed in this ticket

The counts stay useful, so this is neither a WARN nor a refusal — only the claim is narrowed. When memberHerdrSocket is configured the line now names whose environment it counted and says plainly that it is not the member's. The unguarded path keeps its exact original wording, so the existing assertion on "member credentials: allowed 1 of 3" is untouched.

A test pins the pair together so a future edit cannot fix one line and leave the other. Mutation-proved: with the guard removed the test fails printing the old line verbatim, member credentials: allowed 1 of 3.

Lesson

This is the one-way gate shape aimed at my own repair work: a fix applied to the site the report named, not to the class of sites that share the defect. #269 reworded four places and the fifth was two lines away.

Worth noting separately: no test covered #269's own guard. The WARN wording shipped unverified. This ticket adds coverage for the INFO line; the WARN still has none.

Found by a bug-hunt fan-out, verified in the code. **This is a gap in my own #269 fix.** #269 stopped four sites in `HerdrPeerLauncher` from asserting things about the member's environment that fleetd cannot see when `memberHerdrSocket` is configured. The WARN in `logCredentialGap` got a `memberHerdrSocketConfigured()` guard. The INFO line beside it did not. `logAllowListCoverage` is called unconditionally two lines earlier: ```java logAllowListCoverage(allowed); // no guard logCredentialGap(creds, allowed); // guarded since #269 ``` and it reads fleetd's own environment: ```java Set<String> hostNames = hostEnvNames.get(); long kept = hostNames.stream().filter(name -> MemberEnvAllowList.keeps(allowed, name)).count(); log.info("member credentials: allowed {} of {}", kept, hostNames.size()); ``` Read plainly, `member credentials: allowed 7 of 39` is a statement about the member's credentials. Under `memberHerdrSocket` the pane is routed to a second herdr whose environment fleetd has no channel to inspect, so the counts describe fleetd's own process instead. Same overclaim #269 existed to remove, in the line next door. The method's javadoc *does* carry the caveat, via a cross-reference to another field's javadoc. That does not help: the operator reading `fleetd.out` never sees it. ## Fixed in this ticket The counts stay useful, so this is neither a WARN nor a refusal — only the claim is narrowed. When `memberHerdrSocket` is configured the line now names whose environment it counted and says plainly that it is not the member's. The unguarded path keeps its exact original wording, so the existing assertion on `"member credentials: allowed 1 of 3"` is untouched. A test pins the pair together so a future edit cannot fix one line and leave the other. Mutation-proved: with the guard removed the test fails printing the old line verbatim, `member credentials: allowed 1 of 3`. ## Lesson This is the [one-way gate](https://git.ltms.dev/fleet/fleetd/issues/258) shape aimed at my own repair work: a fix applied to the site the report named, not to the class of sites that share the defect. #269 reworded four places and the fifth was two lines away. Worth noting separately: **no test covered #269's own guard.** The WARN wording shipped unverified. This ticket adds coverage for the INFO line; the WARN still has none.
ltms closed this issue 2026-09-04 05:01:48 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#276
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?