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

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

Cerrado
  • ¿Algo no está bien?
#1,599 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, shell
Área
cli, observability

Línea de trabajo

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.

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

Descripción

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.

Lenguaje dominante
Go
Estrellas
115
Forks
14
Merge medio
9 h 44 min
PR fusionados (30 d)
766

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.