Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#23,175 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
developer-experience, tooling

Línea de trabajo

El informe identifica apps/server como el área afectada e indica que la corrección propuesta está en las instrucciones de orquestación y en las descripciones de delegate_task y mode. Empieza por localizar esos textos de orientación y comprobar cómo explican las llamadas wait por lotes. Actualízalos para indicar a los agentes que inicien todos los procesos secundarios con async y conserven cada taskId antes de empezar cualquier espera bloqueante; el trabajo estará terminado cuando las instrucciones expresen claramente este orden.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
1 h 22 min
PR fusionados (30 d)
18

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.