Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

A held (queued) task cannot be stopped and keeps the repo write-lock

已关闭
  • 哪里不对？
#1,571 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
68/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
go
领域
backend, cli, devtools

调研方向

Build dev 837b2b0 and reproduce the held-task flow with task.max_load forced low. Read internal/session/task_run.go:1264 and task_pressure.go:447, then trace admission, folder locking, and the stop path for queued tasks. Done means the e2e cases pass: stopping a held task marks it stopped immediately, and a not-yet-started held task holds no repo write-lock.

由索引模型根据 Issue 内容生成。

描述

area:session bug sev:critical

Seen on: dev 837b2b0.

Behaviour

A senior-dev task held by the busy-machine gate read queued · 10m 47s with no reason. /stop then 1 stop it did not stop it (still queued). While it was held, another team's member could not edit the folder: the repo write-lock is held by the other window's still-running PATCH task. Only restarting the engine ended it, and after the restart tasks.json still said running for that task. A held task should be stoppable, and a task that has not started should not hold the folder's write-lock.

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 for this one (step 5 forces it).
  4. Make a small repo: R=$(mktemp -d) && cd "$R" && git init -q && printf 'package main\n\nfunc main() {}\n' > main.go && printf 'module demo\n\ngo 1.22\n' > go.mod && git add -A && git commit -qm init.
  5. Force the hold: set task.max_load to a value below the machine's current load per core (for example 0.01) under /settings.
  6. Ask a manager to hand a change to senior-dev (or run /task for a small change). The task shows queued.
  7. /stop, choose 1 stop it: the task stays queued.
  8. From another conversation in the same repo, ask for a small edit: it is refused with the write-lock line.

Evidence

  • Screen: queued · 10m 47s; after /stop → 1 stop it, still queued; the other member: the repo write-lock is held by the other window's still-running PATCH task.
  • tasks.json "state": "running", the task folder empty, the task branch already checked out, no model calls for 23 minutes.
  • internal/session/task_run.go:1264: graph.governor = newAdmissionGovernor(a.config.TaskMaxLoad, ...); the hold happens at admission (task_pressure.go:447, heldBy = config.KeyTaskMaxLoad).

Guessed cause

A guess from reading the code, not a confirmed diagnosis. The busy-machine hold happens after the folder lock and branch are taken, and the stop path covers only tasks that have started.

Acceptance

  • e2e: with the gate forced as above, /stop → 1 stop it ends the queued task at once (row stopped), and another conversation can then edit the repo.
  • e2e: while a task is held and not started, no write-lock is held on its repo.

Found while writing the public docs; manual text differences are in #1545.

🤖 Generated with Claude Code

主要语言
Go
星标
115
派生
14
平均合并
9 小时 37 分钟
30 天内合并 PR
755

环境准备

我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Agent-Field/CodeAF 的其他 Issue

查看 Agent-Field/CodeAF 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。