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

Parallel tool calls intermittently lose or mangle `tool_id`

Abierto
  • ¿Algo no está bien?
#3,927 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust, typescript
Área
ai-infra-agents, cli, tooling

Línea de trabajo

The report traces the failure through multi_tool_use.parallel batch assembly and the functions.tool_call wrapper, but does not identify source files or tests. Start by locating those entry points and tracing how nested tool_id values are passed through; internal runtime traces may be needed to distinguish generation from wrapper behavior. Done means malformed IDs are caught before dispatch with a deterministic diagnostic or sequential fallback, with coverage for missing, non-string, and unqualified IDs.

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

Descripción

Checks
Operating system

macOS 26.5.1 (25F80)

Expected behaviour

Expected behavior

Validate each nested call before the parallel batch is dispatched. For every nested item:

  1. tool_id is present,
  2. tool_id is a string,
  3. tool_id is fully namespaced (<server>::<tool>).

If any item fails validation:

  • do not dispatch the batch with the malformed item,
  • return a deterministic, local diagnostic that names the offending item, or
  • fall back to dispatching the calls sequentially.

A clear pre-dispatch validation error (naming which nested call lacks a valid namespaced tool_id)
is far more actionable than the current opaque received undefined.

Actual behaviour

Summary

When the agent emits multiple tool calls in parallel, the runtime wraps them in a
multi_tool_use.parallel payload and converts each nested item into a functions.tool_call.
Intermittently, an individual nested call is malformed: it either omits the required tool_id,
or carries a non-namespaced id (e.g. some_tool instead of server-name::some_tool).

The runtime then rejects the call at input validation, before the tool runs:

Invalid input for tool_call — tool_id: expected string, received undefined

or rejects an unknown (unqualified) tool id before dispatch.

Impact

  • Non-deterministic: the same logical call succeeds on one turn and fails on another.
  • Independent of user-supplied parameters — the arguments object is well-formed; only the
    envelope's tool_id field is affected.
  • Blocks individual steps in multi-step / parallel workflows. The agent must retry, often
    serializing calls as a manual workaround.

Where it happens (observed)

The failure occurs upstream of the actual tool server, in the orchestration chain:

agent output → multi_tool_use.parallel (batch assembly) → functions.tool_call (per-item wrapper) → tool server

By the time the request reaches any downstream MCP server/proxy, it is already a single resolved
call — the tool_id is either present or already lost. The downstream server only sees input
validation fail; it is not the source.

Root cause (hypothesis)

The field is lost or mis-formed at the multi_tool_use.parallel → functions.tool_call step —
either during model generation of the parallel batch, or in the parallel-wrapper orchestration that
converts batch items into individual tool_calls.

Unknown without internal traces: which of the two (model generation vs. wrapper orchestration)
drops the field. This cannot be isolated from outside the runtime.

Steps to reproduce

Reproduction notes

  • Not tied to a specific tool or specific arguments — any parallel batch can exhibit it.
  • Intermittent; higher chance with larger parallel batches.
  • Reproducing reliably likely requires internal runtime tracing of the batch-assembly step.
Environment
<This will be visible to anyone. Do not include personal or sensitive information>

[q-details]
version = "2.29.1"
hash = "31e6bb3fad4a1fff9ba23aee436cef61c8579a58"
date = "2026-10-10T03:23:46.20488Z (1d ago)"
variant = "full"

[system-info]
os = "macOS 26.5.1 (25F80)"
chip = "Apple M4"
total-cores = 10
memory = "24.00 GB"

[environment]
cwd = "/Users/USER/portfolio-agent-runtime"
cli-path = "/Users/USER/portfolio-agent-runtime"
os = "Mac"
shell-path = "/bin/zsh"
shell-version = "5.9"
terminal = "iTerm 2"
install-method = "unknown"

[env-vars]
PATH = "/Users/USER/.bun/bin:/Users/USER/.nvm/versions/node/v24.20.0/bin:/Users/USER/Library/Python/3.13/bin:/Users/USER/.local/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/pkg/env/global/bin:/opt/homebrew/bin:/Applications/iTerm.app/Contents/Resources/utilities"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.googlecode.iterm2"
Lenguaje dominante
Rust
Estrellas
2k
Forks
441
Sin PR fusionados en 30 d

Preparar el entorno

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 aws/amazon-q-developer-cli

Todos los issues de aws/amazon-q-developer-cli

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.