Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#1,599 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, shell
領域
cli, observability

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Go
スター
115
フォーク
14
平均マージ
9時間 37分
マージ済み PR（30日）
755

環境構築

このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Agent-Field/CodeAF のほかの issue

Agent-Field/CodeAF の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。