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

Checker spend ceiling is shared by the whole run, and the run still says done

Aperta
  • Qualcosa non va?
#1,572 0 commenti 0 reazioni 1 assegnatario 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
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, cli

Direzione di ricerca

Start with internal/config/crewspend.go:100-125 and internal/session/taskcrew.go:560, then reproduce the documented multi-part run using the dev build and inspect its plandb check rows. Trace how checker ceilings are assigned and how failed checks affect the landing summary. Done means each check has its own ceiling and any unfinished check prevents a done status and is named in the landing line.

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

Descrizione

area:session bug sev:critical

Seen on: dev 837b2b0.

Behaviour

In a fan-out run, most per-part checks end failed: the check stopped at its spend ceiling of $0.75, three times its estimate, before it finished: 16 of 20 checks (run 1) and 9 (run 2) in one lane, 5 of 8 and 93 of 100 in another. Each run still ended done, and the summary read "All 20 issues … done". A check that could not finish is not a passed check, and the ceiling reads as per check but behaves as one pool for the run.

Replication

  1. Build dev 837b2b0 (git checkout 837b2b0 && make build, binary bin/codeaf), or install the dev build with curl -fsSL https://agentfield.ai/get/devaf | bash.
  2. Use an isolated profile: export HOME=$(mktemp -d), export OPENROUTER_API_KEY, and keep the default model (~deepseek/deepseek-v4-flash-latest, crew on auto).
  3. On a busy machine set task.max_load to 0 (/settings, Tasks) so the busy-machine gate does not hold tasks.
  4. Make a small repo with many parts: R=$(mktemp -d) && cd "$R" && git init -q && printf 'package main\n\nfunc main() {}\n' > main.go && printf 'module demo\n\ngo 1.22\n' > go.mod && git add -A && git commit -qm init, then create 20 small Go files issue_01.go … issue_20.go, each with one trivial function and a failing test, and commit.
  5. codeaf, then /task Fix every failing test, one part per file issue_NN.go, with a check on every part.
  6. When the run lands, read its plan store (plandb list in the run, or the tasks table of the run's plandb.db): count check: rows with failed: the check stopped at its spend ceiling. Compare with the run's landing line.

Evidence

  • Check rows: failed: the check stopped at its spend ceiling of $0.75, three times its estimate, before it finished (16/20, 9/20, 5/8, 93/100 across four runs); every run ended done.
  • internal/config/crewspend.go:100-118: CrewSeatCeilings returns one ceiling for the crewroute.Checker seat ("THE CEILING BELONGS TO THE SEAT"); crewspend.go:125 is the sentence.
  • internal/session/taskcrew.go:560: SeatCeilings: config.CrewSeatCeilings(d) is set once per crew, so every check in the run draws from it.

Guessed cause

A guess from reading the code, not a confirmed diagnosis. The seat ceiling is keyed per run (the checker seat), not per check, so later checks find it spent. Failed checks are not counted in the landing summary, so the run reports done.

Acceptance

  • e2e: the 20-part run above ends with every check either holding or failing on its own merits; no check ends at a ceiling set for another part.
  • e2e: a run with any check that did not finish does not end done; its landing line names the unfinished checks.

Found while writing the public docs; manual text differences are in #1545.

🤖 Generated with Claude Code

Lingua principale
Go
Stelle
115
Fork
14
Merge medio
9h 37m
PR unite (30g)
755

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.