[Bug]: Use the team's tasks with unlimited queuing

[trainliang]

Deployment type

Official App

What happened?

Use the team's tasks with unlimited queuing

Steps to reproduce

1. Create issues and assign them to the team
2. Start entering the queue
3. Enter a loop of infinite queuing, including discussions; as long as it is assigned to the team, it will endlessly queue

Screenshots (optional)

23:53:52.194 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=a286db7a-64ea-41df-9078-a11cb642a60a
23:53:56.893 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af
23:54:02.494 WRN claim task failed component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af error="context deadline exceeded (Client.Timeout or context cancellation while reading body)"
23:54:05.724 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=37a50f92-6eb7-4500-89a7-ade2abad856c
23:54:07.193 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=a286db7a-64ea-41df-9078-a11cb642a60a
23:54:09.018 DBG workspace sync: fetched workspaces component=daemon count=1
23:54:11.894 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af
23:54:20.726 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=37a50f92-6eb7-4500-89a7-ade2abad856c
23:54:22.194 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=a286db7a-64ea-41df-9078-a11cb642a60a
23:54:26.896 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af
23:54:29.086 DBG workspace sync: fetched workspaces component=daemon count=1
23:54:29.888 DBG heartbeat: pending actions component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af update=false model_list=true local_skills=false local_skill_import=false
23:54:29.889 INF model list requested component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af request_id=e4516972c61f88c3419b402e7a7aeed4 provider=claude
23:54:35.727 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=37a50f92-6eb7-4500-89a7-ade2abad856c
23:54:37.194 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=a286db7a-64ea-41df-9078-a11cb642a60a
23:54:41.894 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af
23:54:50.729 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=37a50f92-6eb7-4500-89a7-ade2abad856c
23:54:52.194 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=a286db7a-64ea-41df-9078-a11cb642a60a
23:54:56.894 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af
23:54:59.831 DBG workspace sync: fetched workspaces component=daemon count=1
23:55:05.725 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=37a50f92-6eb7-4500-89a7-ade2abad856c
23:55:07.194 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=a286db7a-64ea-41df-9078-a11cb642a60a
23:55:11.892 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af
23:55:20.724 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=37a50f92-6eb7-4500-89a7-ade2abad856c
23:55:22.193 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=a286db7a-64ea-41df-9078-a11cb642a60a
23:55:26.892 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af
23:55:32.678 WRN claim task failed component=daemon runtime_id=3d6485f9-ad28-428b-b774-4a46dd2834af error="context deadline exceeded (Client.Timeout or context cancellation while reading body)"
23:55:35.725 DBG heartbeat: skipping HTTP tick, WS recently acked component=daemon runtime_id=37a50f92-6eb7-4500-89a7-ade2abad856c

Additional context (optional)

[YOMXXX]

Thanks for reporting. I think this is potentially important, but the current repro is still too ambiguous for reviewers/triage to distinguish between a queue de-dupe bug, a squad/team assignment loop, and an agent-comment re-trigger loop.

Could you add a bit more data?

• Does "team" mean a squad/team assignment, or assigning issues to multiple individual agents?
• One or two affected issue IDs, plus the workspace/team/squad name if safe to share.
• A screenshot or copied task queue rows showing the repeated queued tasks, especially task IDs/statuses if visible.
• Whether the loop is triggered by new comments/discussions, by the original assignment, or by agent-generated comments.
• Expected behavior: should there be only one active/queued task per issue per assigned team until completion?
• Approximate time window/timezone when it happened on the official app.

If this is triggered by squad members reporting back concurrently and waking the leader repeatedly, it may be related to #3136; otherwise it likely needs a separate queue de-duplication fix.

[trainliang]

感谢你的报告。我认为这可能很重要，但当前的复刻版对审核员和分诊来说仍然太模糊，无法区分队列去重的漏洞、小队/团队分配循环和代理评论的重新触发循环。

你能补充一些数据吗？

• “团队”是指一个小队/团队的分配，还是指将问题分配给多个独立的特工？
• 一两个受影响的问题ID，以及如果安全可以分享的工作区/团队/小队名称。
• 截图或复制的任务队列行，显示重复排队任务，尤其是任务ID和状态（如果可见的话）。
• 循环是由新评论/讨论触发、原始作业触发，还是由代理生成的评论触发。
• 预期行为：每个分配团队是否应该在完成前每个问题只进行一个活跃/排队任务？
• 官方应用上大致的时间窗口/时区。

如果是因为小队成员同时报告并多次唤醒队长触发，可能与#3136有关;否则可能需要单独的队列去重修复。

1.squads
2.trainliang-space/issues/197bee19-606f-49ad-9e40-c8aa6e6e417e
agents/7d4c7ff9-67a7-4262-ab11-1c073b4ea043

A large number of tasks cannot be scheduled; after reinstalling, restarting, and re-authenticating, the task nodes still cannot be restored or scheduled normally.

[vicksiyi]

Thanks for the report. I opened PR #5624 with a fix: #5624

Root cause: the batch claim path listed every queued task for a team/squad leader before deduping by agent, so a large team queue could exceed the daemon claim deadline while dispatching at most one leader task per poll.
Fix: claim candidate listing is now bounded to one representative per runtime/agent, and the batch loop can reuse free slots for the same agent while ClaimTask still enforces capacity and serialization.
Validation: cd server && go test ./internal/service; cd server && go test ./internal/handler -run 'TestClaimTasksByRuntime|TestClaimTaskByRuntime'; make check-worktree exited 0 locally but printed Docker unavailable while checking PostgreSQL.

I will keep an eye on CI and review feedback.