Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Bug]: Batched `delegate_task` wait calls start children one at a time, but the parent reports both running

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#23,175 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
74/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
developer-experience, tooling

Hướng nghiên cứu

Báo cáo xác định apps/server là khu vực bị ảnh hưởng và cho biết bản sửa được đề xuất nằm trong các hướng dẫn điều phối cùng phần mô tả delegate_task và mode. Trước tiên, hãy tìm các nội dung hướng dẫn đó và kiểm tra cách chúng giải thích các lệnh gọi wait theo lô. Cập nhật chúng để yêu cầu các agent khởi chạy tất cả tiến trình con bằng async và lưu lại từng taskId trước khi bắt đầu bất kỳ lần chờ chặn nào; hoàn tất khi hướng dẫn nêu rõ thứ tự này.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug needs-triage
Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/server

Steps to reproduce
  1. Start a thread with Codex or Claude Code as the agent and the T3 delegation tools available.
  2. Have the agent submit two delegate_task calls together. Use mode: "wait", timeoutMs: 10000, and a read-only child task that runs longer than the wait.
    • In Codex code mode, run the cell below in one functions.exec call.
    • In Claude Code, have the agent emit the same two calls as parallel tool uses in one assistant message.
  3. In the server traces, compare when T3 receives each delegate_task HTTP request with when the first call returns.
const runId = "parallel-probe-1"; // use a new value for each run
const results = await Promise.allSettled(
	["a", "b"].map((seat) =>
		tools.mcp__t3_code__delegate_task({
			clientRequestId: `${runId}-${seat}`,
			title: `Parallel delegation probe ${seat}`,
			target: {
				providerInstanceId: "codex",
				model: "gpt-6.1-sol",
				options: { reasoningEffort: "high", serviceTier: "default" },
			},
			isolation: "shared",
			mode: "wait",
			timeoutMs: 10000,
			task: "Run `sleep 15`, then reply PROBE_COMPLETE. Do not edit files or delegate.",
		}),
	),
);
results.forEach((result) => text(JSON.stringify(result)));

I did not run this exact cell. The tested runs gave the children the same work through file-backed prompts. The Claude Code run used these wait and delay values. The Codex runs used shorter and longer waits.

Expected behavior

When an agent intends to run two children in parallel, both children start. The agent reports a child as running only after T3 returns its taskId and a running status.

T3 does not promise that mode: "wait" calls dispatch in parallel. The mode description says only that a wait blocks until completion, a blocking question, a pending approval, or timeout. It does not tell the agent that a blocking call can hold back other calls submitted with it. Either the calls dispatch concurrently, or the guidance tells the agent to launch every child with mode: "async" before it waits on any of them.

Actual behavior

The second child starts only after the first wait returns. In the original incident, the parent reported both as running before the second child existed.

In the controlled Claude Code run, both complete tool uses were in one assistant message. B's arguments were ready about 8 seconds before A's response finished. Even so, T3 received B's HTTP request 18 ms after A's response finished. Codex code mode showed the same order with Promise.allSettled.

In the original Codex incident, only the first child existed after about two minutes, but the agent reported both as running. The user found the missing child. The agent then launched it with mode: "async", and T3 accepted that call while the first wait was still open. The original batched call reached T3 about three and a half minutes later, after the first wait returned. It reused the same clientRequestId, so it returned the existing child. No request was lost, no transport failed, and T3 created no duplicate child.

The delay happens before T3 receives the second request. T3 accepted another delegation during the wait, so T3 does not hold a server-wide lock. This report covers two calling paths, Codex code mode and Claude Code direct parallel tool uses, not every runtime or MCP tool. The scheduling policy inside each runtime is unknown. Whether T3 can change its runtime integration is an open question, but T3 owns the launch guidance that agents follow.

Related issues, with no confirmed duplicate:

  • #11168: a blocking wait fails at a client timeout and returns no task ID. Here, both calls succeed, and the second call is late.
  • #16621: child cards disappear after the children exist. Here, the second child does not exist yet.
Impact

Minor bug or occasional failure

Version or commit

0.1.2-nightly.20261021.3473

Environment

Debian 13 Linux backend; Codex MCP client 0.163.0; provider/model codex / gpt-6.1-sol;

Logs or stack traces
# All times UTC on 2026-10-21. A and B are the two delegate_task calls.

# Controlled run: Claude Code parent, 10000 ms waits, children run past the wait
23:58:54.843  A: complete tool-use arguments emitted
23:58:54.853  T3 receives A HTTP request
23:58:56.879  B: complete tool-use arguments emitted in the same assistant message
23:59:04.923  A: HTTP response finishes, waitTimedOut=true
23:59:04.941  T3 receives B HTTP request
23:59:14.993  B: HTTP response finishes, waitTimedOut=true

# Original incident: Codex code mode, Promise.allSettled, 30-minute waits
23:24:02.000  T3 receives A HTTP request
23:25:50.530  Thread list shows only child A
23:25:58.367  T3 receives a separate async request for B
23:25:58.412  T3 creates child B
23:29:22.898  A: MCP call completes
23:29:22.900  T3 receives the original batched B request
Screenshots, recordings, or supporting files

No response

Workaround

Launch every child with mode: "async" and keep each returned taskId. Report a child as running only after T3 returns its taskId and a running status. Start any blocking wait only after every launch returns.

I have a local change that adds this order to the orchestration instructions and to the delegate_task and mode descriptions. It changes only the guidance, not how calls dispatch.

Ngôn ngữ chính
TypeScript
Star
24.8k
Fork
6.4k
Merge trung bình
1 giờ 22 phút
Pull request đã merge (30 ngày)
18

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pingdotgg/t3code

Tất cả issue của pingdotgg/t3code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.