Skip to content

A task held as machine busy shows no reason; max_load changes need a restart #1579

Closed

Description

@santoshkumarradha

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

  1. Build dev 837b2b0 (git checkout 837b2b0 && make build), or install the dev build with curl -fsSL https://agentfield.ai/get/devaf | bash.
  2. Use an isolated profile: export HOME=$(mktemp -d), export OPENROUTER_API_KEY, default model.
  3. Leave the busy-machine gate ON (step 5 forces it).
  4. cd $(mktemp -d) && git init -q && codeaf.
  5. Force the hold: set task.max_load below the current load per core (for example 0.01) in /settings.
  6. /task add a README.md with one line. Read the rail row and the task page.
  7. Set task.max_load back to 0: the task stays held until codeaf engine --stop and a relaunch.

Evidence

  • Rail: Waiting 1 ▸ with no reason; task page queued · 10m 47s.
  • internal/session/task_pressure.go:249-267 builds the machine busy reason words; internal/tui3/task.go:780 (waitWordMachine), internal/tui3/room.go:3298-3302 and internal/tui3/tasksplace.go:1891 draw railParked words only.
  • internal/session/task_run.go:1264: the governor is built once from a.config.TaskMaxLoad when 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_load to 0 in /settings admits 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

Activity

  1. added
    bugSomething the code does that it should not
    area:chatThe v3 surface a person sits in front of (internal/tui3)
    area:sessionThe engine — turns, tasks, the toolbelt, checkpoints
    sev:seriousWrong or missing behaviour a person meets in ordinary use
    on Sep 27, 2026
  2. added 2 commits that reference this issue on Sep 27, 2026
    88db9fc
    153eb04
  3. santoshkumarradha commented on Oct 23, 2026

    @santoshkumarradha
    MemberAuthor

    Audited on current dev (39fdbea6f73c). The implementation landed in #1627 (ac84606f4429). Fresh tests verify both parts of the report:

    • Graph and delegated-run admission refresh task.max_load/free-memory settings without restart, including changes made by another process (TestMachineAdmissionRefreshesBothCeilingsWithoutRestart, TestMachineAdmissionNoticesSettingsFromAnotherProcess, and the named-ceiling control; 0.073 seconds).
    • Plan rows and rooms retain the machine-hold reason and queued state (TestAHeldPlanRailRowKeepsItsReasonAndQueuedRoomState and 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:chatThe v3 surface a person sits in front of (internal/tui3)area:sessionThe engine — turns, tasks, the toolbelt, checkpointsbugSomething the code does that it should notsev:seriousWrong or missing behaviour a person meets in ordinary use

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions