Symptom
On a machine whose Docker VM shrank under the configured ceiling (observed: WSL2 backend giving the node ~6.7 GiB while RESOURCE_LIMITS still carried the chart default memory=8Gi), the resources set wizard offers a default it then rejects:
? Memory for one run in GiB (2–3) [? for help] (8) ← Enter / accepting the default…
X Sorry, your reply was invalid: must be between 2 and 3
The header above it is equally off: Memory: 8 of 6.7 GiB (>100%).
Root cause
internal/cli/resources_set.go:414-424 — the prompt defaults are the current cluster-wide ceiling (coresNum(current.CPU), gibNum(current.Mem) from the jobs-manager RESOURCE_LIMITS, default cpu=2,memory=8Gi per internal/resources/resources.go:34,100-106) passed verbatim, while the validator range comes from the largest node: boundedInt(2, maxGiB) with maxGiB = MaxRunGiB(node) = floor(6.7 − 3) = 3 (internal/resources/set.go:141-147). Nothing clamps the default into the range, and survey validates the default on Enter (internal/cli/interactive.go:56-72), so accepting the offer errors. CPU escapes only by luck (default 2 ∈ [1,11]).
The header at resources_set.go:370-371 mixes the same two frames (current ceiling vs node capacity), printing "8 of 6.7 GiB".
The no-op path already handles the machine-shrank-under-ceiling case explicitly (resources_set.go:229-247) — the wizard defaults were just never given the same treatment.
Fix
- Clamp both prompt defaults into their validator range before passing to
pr.Input: clamped = min(max(current, floor), max) (memory floor 2, CPU floor 1). - Header: when
current > node capacity, don't print "8 of 6.7" as-is — either show the clamped effective value or annotate ("8 GiB configured — this machine can allocate up to 3 GiB"). - Test gap: the prompter fake already validates defaults (
interactive_test.go:34-42) but no test scripts an out-of-range default — add one (node 6.7 GiB + current 8Gi ⇒ default shown must be accepted by Enter).
Acceptance
Symptom
On a machine whose Docker VM shrank under the configured ceiling (observed: WSL2 backend giving the node ~6.7 GiB while
RESOURCE_LIMITSstill carried the chart defaultmemory=8Gi), theresources setwizard offers a default it then rejects:The header above it is equally off:
Memory: 8 of 6.7 GiB(>100%).Root cause
internal/cli/resources_set.go:414-424— the prompt defaults are the current cluster-wide ceiling (coresNum(current.CPU),gibNum(current.Mem)from the jobs-managerRESOURCE_LIMITS, defaultcpu=2,memory=8Giperinternal/resources/resources.go:34,100-106) passed verbatim, while the validator range comes from the largest node:boundedInt(2, maxGiB)withmaxGiB = MaxRunGiB(node)=floor(6.7 − 3) = 3(internal/resources/set.go:141-147). Nothing clamps the default into the range, and survey validates the default on Enter (internal/cli/interactive.go:56-72), so accepting the offer errors. CPU escapes only by luck (default 2 ∈ [1,11]).The header at
resources_set.go:370-371mixes the same two frames (currentceiling vsnodecapacity), printing "8 of 6.7 GiB".The no-op path already handles the machine-shrank-under-ceiling case explicitly (
resources_set.go:229-247) — the wizard defaults were just never given the same treatment.Fix
pr.Input:clamped = min(max(current, floor), max)(memory floor 2, CPU floor 1).current > node capacity, don't print "8 of 6.7" as-is — either show the clamped effective value or annotate ("8 GiB configured — this machine can allocate up to 3 GiB").interactive_test.go:34-42) but no test scripts an out-of-range default — add one (node 6.7 GiB + current 8Gi ⇒ default shown must be accepted by Enter).Acceptance