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

CB-585: maxLoad: 0 caps a profile at zero, negative refused at load #70

Closed
agent wants to merge 0 commits from worker/cb585-maxload-zero-4585c4-3 into main
pull from: worker/cb585-maxload-zero-4585c4-3
merge into: fleet:main
Conversation 0 Commits - Files Changed -
agent commented 2026-08-15 15:39:10 +02:00
Member
Copy Link
Copy Source

Fixes gitea issue #66 (CB-585).

BridgedConfig.Profile's compact constructor was normalising maxLoad: 0 to null (unlimited) — the same shape of bug CB-554 fixed for weight this morning. An operator writing maxLoad: 0 to mean "never run anything here" got the exact opposite: no cap at all. On a subscription: true profile, maxLoad is the only throttle against the operator's own paid plan.

Change

  • BridgedConfig.Profile compact constructor: maxLoad no longer coerces an explicit 0 back to null. Absent/null still means unlimited.
  • New BridgedConfig.rejectNegativeMaxLoad, wired into load() alongside the other reject* config-load guards: a negative maxLoad is refused at load with an IllegalStateException naming the profile and the key, mirroring rejectRenamedTopLevelKeys/rejectLeaderTerminalKey.
  • bridged.example.yaml: documented the new maxLoad: 0 meaning next to the existing weight doc.

Criterion 5 — explicit spawn against a maxLoad: 0 profile

Decided: it is refused, same as an automatic placement would be. Checked CompositePeerLauncher.spawn/enforceMaxLoad first (CB-553) — it already enforces live >= cap unconditionally on every explicit-profile spawn, with no fallback. Once the compact constructor stops nulling maxLoad: 0 to null, that existing check refuses the spawn for free (0 live >= 0 cap) — no new filter needed. Added CompositePeerLauncherTest#explicitSpawnOnMaxLoadZeroProfileIsRefusedEvenWithZeroLiveWorkers to lock this in; before the fix it would have spawned instead of refusing.

Config impact (please check the live bridged.yaml before merging)

Any profile in the live config that currently sets maxLoad: 0 changes behaviour under this PR: today it silently means unlimited; after this merges it means "never run anything here" (both for automatic placement, which already excludes at-cap candidates via PlacementPolicyUtil.available(), and for an explicit bridge_spawn{profile:...}, which is now refused). Any profile with a negative maxLoad will refuse the daemon to start until fixed. I cannot see bridged.yaml (gitignored) so I can't confirm whether either case is present live.

Tests

mvn clean install — Tests run: 769, Failures: 0, Errors: 0, Skipped: 0. BUILD SUCCESS. New/updated tests: 2 in BridgedConfigTest, 1 in CompositePeerLauncherTest, 2 in PlacementPolicyTest.

Fixes gitea issue #66 (CB-585). `BridgedConfig.Profile`'s compact constructor was normalising `maxLoad: 0` to `null` (unlimited) — the same shape of bug CB-554 fixed for `weight` this morning. An operator writing `maxLoad: 0` to mean "never run anything here" got the exact opposite: no cap at all. On a `subscription: true` profile, `maxLoad` is the only throttle against the operator's own paid plan. ## Change - `BridgedConfig.Profile` compact constructor: `maxLoad` no longer coerces an explicit `0` back to `null`. Absent/`null` still means unlimited. - New `BridgedConfig.rejectNegativeMaxLoad`, wired into `load()` alongside the other `reject*` config-load guards: a negative `maxLoad` is refused at load with an `IllegalStateException` naming the profile and the key, mirroring `rejectRenamedTopLevelKeys`/`rejectLeaderTerminalKey`. - `bridged.example.yaml`: documented the new `maxLoad: 0` meaning next to the existing `weight` doc. ## Criterion 5 — explicit spawn against a maxLoad: 0 profile Decided: it is refused, same as an automatic placement would be. Checked `CompositePeerLauncher.spawn`/`enforceMaxLoad` first (CB-553) — it already enforces `live >= cap` unconditionally on every explicit-profile spawn, with no fallback. Once the compact constructor stops nulling `maxLoad: 0` to `null`, that existing check refuses the spawn for free (`0 live >= 0 cap`) — no new filter needed. Added `CompositePeerLauncherTest#explicitSpawnOnMaxLoadZeroProfileIsRefusedEvenWithZeroLiveWorkers` to lock this in; before the fix it would have spawned instead of refusing. ## Config impact (please check the live bridged.yaml before merging) Any profile in the live config that currently sets `maxLoad: 0` changes behaviour under this PR: today it silently means unlimited; after this merges it means "never run anything here" (both for automatic placement, which already excludes at-cap candidates via `PlacementPolicyUtil.available()`, and for an explicit `bridge_spawn{profile:...}`, which is now refused). Any profile with a negative `maxLoad` will refuse the daemon to start until fixed. I cannot see `bridged.yaml` (gitignored) so I can't confirm whether either case is present live. ## Tests `mvn clean install` — Tests run: 769, Failures: 0, Errors: 0, Skipped: 0. BUILD SUCCESS. New/updated tests: 2 in `BridgedConfigTest`, 1 in `CompositePeerLauncherTest`, 2 in `PlacementPolicyTest`.
agent added 1 commit 2026-08-15 15:39:10 +02:00
CB-585: maxLoad: 0 caps a profile at zero, negative refused at load
CI / contract (pull_request) Successful in 41s
Details
CI / build (pull_request) Successful in 1m18s
Details
2f8c98dac9
ltms closed this pull request 2026-08-15 16:01:04 +02:00
ltms deleted branch worker/cb585-maxload-zero-4585c4-3 2026-08-15 16:01:04 +02:00
Some checks are pending
CI / contract (pull_request) Successful in 41s
Details
CI / build (pull_request) Successful in 1m18s
Details

Pull request closed

This pull request cannot be reopened because the branch was deleted.
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#70
Delete Branch "worker/cb585-maxload-zero-4585c4-3"

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?