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

A worker step cap permits every call in one model reply

Abierto
  • ¿Algo no está bien?
#1,459 0 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
bash, go
Área
backend, documentation, testing-qa

Línea de trabajo

Read internal/session/loop.go around runToolsWarm and the end-event send, then inspect internal/run/bashworker.go around the step-cap handling. Run the deterministic internal/run two-call test described in the issue and review docs/changes/unreleased/1410-worker-step-boundary.md. Done means the chosen batch boundary is pinned by unit and e2e coverage and the manual and change entry match it.

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

Descripción

area:session bug sev:papercut

Found on santos/dev2 at 008363c98 (#1410). It reaches dev when #1410 merges.

What happened

The step handshake stops a worker before its next model request, but runToolsWarm runs every call in one reply's batch before sending the first end event. With a cap of one, a reply containing two tool calls executes both. The batch behavior predates the handshake; the new change entry overstates it as before the next action can start.

Replication

Deterministic (no model). In internal/run, script one model reply with two observable bash calls, set WithStepsPerTask(..., 1), and run the worker. Today both effects occur before the worker reports its step cap. A one-call reply is the control.

Field (real models). Ask a task to perform two separate shell actions in its first reply with a one-step cap in a controlled run; a model may combine the calls, so the deterministic test is the acceptance gate. Use OPENROUTER_API_KEY, deepseek/deepseek-v4-flash and a small charge if exercising this door.

Where

internal/session/loop.go:3350, runToolsWarm, finishes a batch before the end-event send at :3415; internal/run/bashworker.go:253 applies the cap after receiving an end event. docs/changes/unreleased/1410-worker-step-boundary.md:7 describes a stronger boundary.

The fix

Enforce the cap between calls in a batch if it is a per-action limit; otherwise name it a per-model-request limit consistently in code, UI and docs.

Acceptance

  • e2e: a task with cap one and a two-call scripted reply records only the permitted effect, or its visible contract explicitly says both calls are one permitted batch.
  • Unit: a two-call batch pins the chosen boundary.
  • Correct the manual and the change entry's invalidates.
Lenguaje dominante
Go
Estrellas
115
Forks
14
Merge medio
9 h 35 min
PR fusionados (30 d)
752

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 Agent-Field/CodeAF

Todos los issues de Agent-Field/CodeAF

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.