Repository navigation
A task held as machine busy shows no reason; max_load changes need a restart #1579
Copy link
Copy link
Closed
Labels
area:chatThe v3 surface a person sits in front of (internal/tui3)The v3 surface a person sits in front of (internal/tui3)area:sessionThe engine — turns, tasks, the toolbelt, checkpointsThe engine — turns, tasks, the toolbelt, checkpointsbugSomething the code does that it should notSomething the code does that it should notsev:seriousWrong or missing behaviour a person meets in ordinary useWrong or missing behaviour a person meets in ordinary use
Milestone
Description
Seen on: dev 837b2b0.
Behaviour
A task held by the busy-machine gate sits under Waiting 1 ▸ on the rail with no reason (at 215 columns), and the task page read queued · 10m 47s with no reason, while no model call is made for minutes. The manual promises waiting · machine busy · load per core at or above task.max_load 1.5. Also, changing task.max_load does not free a held task until the engine restarts.
Replication
- Build dev 837b2b0 (
git checkout 837b2b0 && make build), or install the dev build withcurl -fsSL https://agentfield.ai/get/devaf | bash. - Use an isolated profile:
export HOME=$(mktemp -d), exportOPENROUTER_API_KEY, default model. - Leave the busy-machine gate ON (step 5 forces it).
cd $(mktemp -d) && git init -q && codeaf.- Force the hold: set
task.max_loadbelow the current load per core (for example0.01) in/settings. /task add a README.md with one line. Read the rail row and the task page.- Set
task.max_loadback to0: the task stays held untilcodeaf engine --stopand a relaunch.
Evidence
- Rail:
Waiting 1 ▸with no reason; task pagequeued · 10m 47s. internal/session/task_pressure.go:249-267builds themachine busyreason words;internal/tui3/task.go:780(waitWordMachine),internal/tui3/room.go:3298-3302andinternal/tui3/tasksplace.go:1891drawrailParkedwords only.internal/session/task_run.go:1264: the governor is built once froma.config.TaskMaxLoadwhen the graph is made.
Guessed cause
A guess from reading the code, not a confirmed diagnosis. The rail renders the railParked group without status.Reason, and the admission governor reads task.max_load once, so a changed setting does not reach it.
Acceptance
- e2e: with the hold forced, the rail row and the task page both read
waiting · machine busy · load per core at or above task.max_load …. - e2e: setting
task.max_loadto0in/settingsadmits the held task within a few seconds, with no restart.
Found while writing the public docs; manual text differences are in #1545.
🤖 Generated with Claude Code
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area:chatThe v3 surface a person sits in front of (internal/tui3)The v3 surface a person sits in front of (internal/tui3)area:sessionThe engine — turns, tasks, the toolbelt, checkpointsThe engine — turns, tasks, the toolbelt, checkpointsbugSomething the code does that it should notSomething the code does that it should notsev:seriousWrong or missing behaviour a person meets in ordinary useWrong or missing behaviour a person meets in ordinary use
Activity
tasks: a held task says machine busy, stops from the main box, follow…
tasks: task.max_load changes reach the engine process, and an interru…
Consolidate verified CodeAF task, chat and runtime fixes (#1627)
fix: recover and cancel tasks with durable admission state
santoshkumarradha commentedon Oct 23, 2026
Audited on current
dev(39fdbea6f73c). The implementation landed in #1627 (ac84606f4429). Fresh tests verify both parts of the report:task.max_load/free-memory settings without restart, including changes made by another process (TestMachineAdmissionRefreshesBothCeilingsWithoutRestart,TestMachineAdmissionNoticesSettingsFromAnotherProcess, and the named-ceiling control; 0.073 seconds).TestAHeldPlanRailRowKeepsItsReasonAndQueuedRoomStateand related held-plan checks; 0.041 seconds).Closing as completed by #1627. These are current deterministic admission/rendering checks, not a new live-provider reproduction.