Block a user
fleet_ack says "acknowledged <msgId>" for a held peer message it never touches
Decision: option 2, refuse. But one premise in this ticket is wrong, and the correction matters.
I read the code myself before deciding, and axis 1 above is wrong on its load-bearing…
Deleting any of the four startup report calls from Fleetd.main leaves the suite green
Deleting any of the four startup report calls from Fleetd.main leaves the suite green
Fixed and merged as PR #445, on main at 82fae94.
FleetdStartupReportTest now pins all four startup reports in Fleetd.main. The seam is that the reports run before cfg.validateAll()…
ltms
deleted branch worker/442-pin-startup-report-calls-ad9c1b-15 from fleet/fleetd
2026-09-10 11:30:33 +02:00
fleetd #442: pin startup report calls
fleetd #442: pin startup report calls
Merging. Credit where it belongs: the worker wrote this test. Its backend died mid-turn ("Our servers are currently overloaded") and its worktree was later reaped with the member, so it never…
ltms
pushed to worker/442-pin-startup-report-calls-ad9c1b-15 at fleet/fleetd
2026-09-10 11:30:00 +02:00
coordinatorView reports heldDurable as a hardcoded true, so it cannot go false when durability breaks
Fixed and merged as PR #443, on main at 3f807d9.
What changed. coordinatorView reported heldDurable as a literal true (FleetMcp.java:1418), so the field could never say false…
3f807d9f1b
Merge #443: derive coordinator.heldDurable from queue durability + ack mode (fleetd #440)
fleetd #440: derive coordinator.heldDurable from queue durability + ack mode
coordinatorView reports heldDurable as a hardcoded true, so it cannot go false when durability breaks
fleet_profiles reports a frozen "default" profile while placement already moved to a new one
PlacementDecision's javadoc claims the place()-to-spawn() window is closed, but no test pins it — and PeerLauncher's default spawn(req, decision) reopens it
fleetd #425 rework: resolve acquireWithWorktree via real placement routing
1a1e586b62
Merge #433: carry the PlacementDecision instead of re-resolving the profile (fleetd #425)
84034b34d1
Merge remote-tracking branch 'origin/main' into worker/425-rework-placement-resolve-c58ba1-9
Deleting any of the four startup report calls from Fleetd.main leaves the suite green
Nothing warns that a profile has no usage-limit detection, so "off when the subscription limit is reached" silently covers only the profiles that opted in
Nothing warns that a profile has no usage-limit detection, so "off when the subscription limit is reached" silently covers only the profiles that opted in
Closing this as a duplicate. The feature already ships, and filing this was my error.
It landed as fleetd #395:
Fleetd.java:141—reportExhaustedPatternGap(cfg);Fleetd.java:1449…
Nothing warns that a profile has no usage-limit detection, so "off when the subscription limit is reached" silently covers only the profiles that opted in