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

fleetd #669: report that a collaborator change needs a restart #707

Closed
ltms wants to merge 0 commits from worker/669-collab-reload-report-2a21bd-4 into main
pull from: worker/669-collab-reload-report-2a21bd-4
merge into: fleet:main
Conversation 1 Commits - Files Changed -
ltms commented 2026-10-04 06:18:56 +02:00
Owner
Copy Link
Copy Source

fleet.collaborators is read once at startup, to build the LeadTabScanner identity map. A
reload does not rebuild that map. Before this change, ConfigRef said nothing about it, so an
operator who added, removed or re-tabbed a collaborator saw a clean reload and no live effect.

changedSplitKeys now compares collaboratorsOf(old) with collaboratorsOf(fresh) and reports
that a restart is needed. The new collaboratorsOf helper mirrors leadersOf, including the
cfg.fleet() == null guard. FleetConfig.java:1271 normalises a null map to empty, so the
helper never returns null.

Two comments were corrected because this change made them false: ConfigRef.java no longer says
"Only fleet.leaders is frozen", and the test javadoc no longer says fleet.leaders is "the
ONLY frozen part".

Tests

Three positive cases — add, remove, change a tab — each assert exactly one split entry with the
expected text. One negative control: an unchanged collaborator block reports nothing. Two
existing tests gained an assertion that the new comparison does not fire on a charter change
or on a leaders-only change, so it cannot pass by reporting on every reload.

Verification by the lead

I did not rely on the worker's build. Merged onto origin/main in a throwaway worktree and ran
mvn clean install myself: exit code 0, BUILD SUCCESS, Tests run: 1996, Failures: 0, Errors: 0, and ConfigRefTest: Tests run: 32, Failures: 0.

The worker also reported a revert proof: removing only the production comparison turned 3 tests
red. I did not re-run that experiment myself.

Opened by the lead. The worker's own Gitea POST was refused by the local safety classifier, and
it correctly did not route around it.

Refs #669.

`fleet.collaborators` is read once at startup, to build the `LeadTabScanner` identity map. A reload does not rebuild that map. Before this change, `ConfigRef` said nothing about it, so an operator who added, removed or re-tabbed a collaborator saw a clean reload and no live effect. `changedSplitKeys` now compares `collaboratorsOf(old)` with `collaboratorsOf(fresh)` and reports that a restart is needed. The new `collaboratorsOf` helper mirrors `leadersOf`, including the `cfg.fleet() == null` guard. `FleetConfig.java:1271` normalises a null map to empty, so the helper never returns null. Two comments were corrected because this change made them false: `ConfigRef.java` no longer says "Only `fleet.leaders` is frozen", and the test javadoc no longer says `fleet.leaders` is "the ONLY frozen part". ## Tests Three positive cases — add, remove, change a tab — each assert exactly one split entry with the expected text. One negative control: an unchanged collaborator block reports nothing. Two existing tests gained an assertion that the new comparison does **not** fire on a charter change or on a leaders-only change, so it cannot pass by reporting on every reload. ## Verification by the lead I did not rely on the worker's build. Merged onto `origin/main` in a throwaway worktree and ran `mvn clean install` myself: exit code 0, `BUILD SUCCESS`, `Tests run: 1996, Failures: 0, Errors: 0`, and `ConfigRefTest: Tests run: 32, Failures: 0`. The worker also reported a revert proof: removing only the production comparison turned 3 tests red. I did not re-run that experiment myself. Opened by the lead. The worker's own Gitea POST was refused by the local safety classifier, and it correctly did not route around it. Refs #669.
ltms added 1 commit 2026-10-04 06:18:56 +02:00
fleetd #669: report collaborator reload restart
CI / shell-tests (pull_request) Failing after 11s
Details
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Failing after 2m1s
Details
f82073717a
ltms commented 2026-10-04 06:20:02 +02:00
Author
Owner
Copy Link
Copy Source

Merged locally in 3e8e314, together with #706. Closing by hand, because a local merge never
closes the PR here.

Verified by the lead before merging, not taken from the worker's report: merged onto origin/main
in a throwaway worktree, then mvn clean install with the output written to a file, not piped —
exit code 0, BUILD SUCCESS, Tests run: 1999, Failures: 0, Errors: 0 on the tree that carries
both PRs. ConfigRefTest: 32, FleetDeliverabilityTest: 9. I checked the pushed tree is
byte-identical to the one I built.

I also checked the two things the diff depends on. Objects was already imported, with 43 uses
before this change. FleetConfig.java:1271 runs collaborators = unmodifiableOrEmpty(collaborators)
in the compact constructor, so collaborators() is never null and collaboratorsOf guards exactly
what leadersOf guards.

Merged locally in `3e8e314`, together with #706. Closing by hand, because a local merge never closes the PR here. Verified by the lead before merging, not taken from the worker's report: merged onto `origin/main` in a throwaway worktree, then `mvn clean install` with the output written to a file, not piped — exit code 0, `BUILD SUCCESS`, `Tests run: 1999, Failures: 0, Errors: 0` on the tree that carries both PRs. `ConfigRefTest: 32`, `FleetDeliverabilityTest: 9`. I checked the pushed tree is byte-identical to the one I built. I also checked the two things the diff depends on. `Objects` was already imported, with 43 uses before this change. `FleetConfig.java:1271` runs `collaborators = unmodifiableOrEmpty(collaborators)` in the compact constructor, so `collaborators()` is never null and `collaboratorsOf` guards exactly what `leadersOf` guards.
ltms closed this pull request 2026-10-04 06:20:20 +02:00
Some checks are pending
CI / shell-tests (pull_request) Failing after 11s
Details
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Failing after 2m1s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
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#707
Delete Branch "worker/669-collab-reload-report-2a21bd-4"

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?