Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,599 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
38/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
go, shell
Bereich
cli, observability

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Go
Sterne
115
Forks
14
Ø Merge
9 Std. 35 Min.
Gemergte PRs (30 T.)
752

Entwicklungsumgebung

Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Agent-Field/CodeAF

Alle Issues in Agent-Field/CodeAF

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.