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

Job logs grow without bound: recursive search of runtime logs consumed 152 GiB and filled disk

Chiusa
  • Qualcosa non va?
#1,599 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à
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, shell
Ambito
cli, observability

Direzione di ricerca

Start with internal/session/jobs.go, especially jobSink.Write and the newJob/claimJobLog path that creates job spools. Trace how stdout and stderr are written, then inspect existing job-related tests before defining coverage for bounded disk usage, truncation or rotation, error reporting, and recursive-search output. Done means sustained output and recursive searches remain bounded while child processes continue draining safely.

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

Descrizione

area:logging area:session bug sev:critical

A recursive search launched by CodeAF consumed approximately 152.6 GiB across four job logs and kept growing until the laptop ran out of space. The search included CodeAF's own runtime log directory, so its output contained deeply nested copies of earlier search output. The disk spool has no size bound even though the in-memory output does.

Observed incident
  • macOS arm64; CodeAF session workspace was $HOME.
  • Logs under $HOME/.codeaf/v3/projects/<project>/<session>/logs/jobs/:
    • 129.log: 64.49 GiB allocated, discovered during follow-up cleanup
    • 150.log: 46.07 GiB
    • 152.log: 27.67 GiB
    • 154.log: 13.62 GiB
  • The initial size snapshot of 150.log, 152.log, and 154.log totaled 87.36 GiB. By cleanup, those three had 88.11 GiB allocated; adding 129.log brings the four-log cleanup total to approximately 152.60 GiB. These are different observation times, not inconsistent totals.
  • Over a three-second observation, 150.log, 152.log, and 154.log grew by approximately 3.0, 2.7, and 2.9 MiB respectively.
  • The laptop reached approximately 117 MiB free, and newly reclaimed cache/download space was being consumed again. An unrelated operation failed with ENOSPC.
  • Three live recursive grep processes were identified and terminated before log cleanup. No CodeAF daemon shutdown was needed to stop those processes.
  • A bounded 16 KiB tail sample from 154.log contained 159 occurrences of /logs/jobs/; the nested matches repeatedly referenced 129.log with line-number prefixes. A separate 64 KiB tail preserved from 129.log shows the same search phrase matched across CodeAF worktrees, stored task transcripts, runtime stubs, and fix records; that sample does not contain nested job-log prefixes or establish the original command that started it. Raw logs are omitted because they include local paths and unrelated user content.

One observed command, with the home path redacted:

grep -rn "git push is not yours to run" "$HOME/.codeaf" /usr/local /opt/homebrew 2> /dev/null

The nested output had this structure (schematic, path/session values removed):

$HOME/.codeaf/.../logs/jobs/129.log:<line>:$HOME/.codeaf/.../logs/jobs/129.log:<earlier-line>:...

This directly establishes that searches were re-ingesting CodeAF job output. A live search reading its own spool is a plausible feedback mechanism, but the preserved tail alone does not establish which process first entered that loop. Later searches also replayed already-amplified output.

Relevant implementation

Inspected source revision: 2d60ab4b3c4ecb70d51a1918d4384db24fd1fb0c (the installed development binary does not embed a usable revision, so this is not asserted to be its exact build).

  • internal/session/jobs.go, jobSink.Write: every chunk is written to the file without a byte budget or rotation; only the in-memory ring is bounded.
  • The same writer ignores file-write errors and always returns success, explicitly including a full disk. That protects the child process but gives no disk-spool failure signal through this writer.
  • newJob / claimJobLog creates the spool that receives both stdout and stderr.
Expected behavior / proposed fix
  1. Bound disk output per job and across retained job logs. Preserve a useful tail and a clear truncation/rotation notice when a limit is reached, while continuing to drain child output safely.
  2. Surface logging failures such as disk exhaustion instead of silently treating the spool as complete.
  3. Prevent generated recursive searches from including CodeAF runtime/spool directories by default, especially when the workspace is $HOME; intentional log inspection should be explicit and bounded.
  4. Add a regression covering a command whose output matches a recursive search of its spool tree, plus a sustained-output case. Verify both disk usage and process cleanup stay bounded.

No large reproduction or test suite was run on the affected laptop. This report is based on the live process/file observations, a bounded log sample, and source inspection. Full acceptance tests for any fix must run on Spark per the owner's standing policy.

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

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.