Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#1,599 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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
平均合并
13 小时 12 分钟
30 天内合并 PR
321

环境准备

我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Agent-Field/CodeAF 的其他 Issue

查看 Agent-Field/CodeAF 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。