cron: run history grows indefinitely and Runs materializes the entire log

[PierrunoYT]

Version / branch / commit

Source-reviewed on main at 99721c7.

OS and environment

Linux amd64; Go 1.26.6. AI-assisted source review. No long-duration disk-exhaustion or memory benchmark was executed.

Steps to reproduce

Suggested bounded test/benchmark, using disposable Store data:

1. Create a cron job.
2. Append increasing numbers of valid RunRecord entries with AppendRun.
3. Observe runs.jsonl size and measure allocations/time for Runs after each increase.
4. Confirm there is no retention or paging boundary as the history grows.

Expected behavior

A recurring background feature should have a bounded way to inspect recent history and a defined retention/rotation mechanism, without silently deleting history users expect to keep. The concrete policy needs maintainer agreement.

Actual behavior / source evidence

AppendRun:303-340 appends one JSON line for each run without rotation or retention.

Runs:343-364 scans the complete file and appends every valid record to a slice. The 1 MiB Scanner limit bounds one record, not total history size. Disk use grows with run count; read time and retained memory grow with the history rather than the requested recent window.

Suggested fix / regression coverage

Add a bounded recent-history/pagination path and agree on a retention policy by count or bytes. If compacting, do it atomically under the existing job lock. Verify newest records survive compaction and concurrent reads remain consistent.

Related work

#971 concerns session directories and checkpoint retention, not cron runs.jsonl. No matching cron-history report was found.

Verification

Existing go test ./... and focused race tests for internal/cron passed. Growth follows directly from the append/read loops; no OOM, disk-full incident, or measured threshold is claimed.

[Vasanthdev2004]

Confirmed on main: AppendRun only ever appends to runs.jsonl, and Runs reads every record into memory, so both grow with the number of runs for as long as the job exists.

Approving. For the policy, I'd keep the newest 1,000 runs per job: compact under the existing job lock when an append takes the file past that (write the kept tail to a temp file and replace), and give Runs a limit that reads only the tail. That bounds every reader and loses nothing anyone is likely to scroll back to. Unless someone objects here, a PR can take that number.