Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

A worker step cap permits every call in one model reply

Aperta
  • Qualcosa non va?
#1,459 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
62/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
bash, go
Ambito
backend, documentation, testing-qa

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Go
Stelle
115
Fork
14
Merge medio
9h 38m
PR unite (30g)
749

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Agent-Field/CodeAF

Tutte le issue di Agent-Field/CodeAF

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.