gramps
b1d6034662
The creator (2026-10-09): 'we need some sort of log-rotation so that we don't inadvertently fill up a user's drive.' startup.log was uncapped - 23MB and growing every few seconds, because FfmpegEncoder logs every non-progress ffmpeg stderr line. The policy lives in a new Helpers/LogRotation.cs as a pure function over a path (RollIfNeeded(logPath, maxBytes, retainedFiles)), so AppLog's 156 call sites keep their surface and the rule is testable on its own. At 5MB the live file rolls to startup.1.log and one rolled copy is kept - the FILE SET is bounded, not just the live file, so a long stream cannot grow the log without limit. A failed rotation degrades to the old behaviour instead of taking the app down. Pattern reference (cited): Serilog's file sink pairs fileSizeLimitBytes (the cap) with retainedFileCountLimit (how many rolled files to keep) - https://github.com/serilog/serilog-sinks-file Guard: ytLive.Tests/AppLogRotationTests.cs - the ONE test drives the real AppLog.Write against a temp dir (two internal seams: PathOverride, MaxBytes) and asserts the roll, the fresh live file, and that after a SECOND roll the directory still holds exactly startup.log + startup.1.log. Also fixed a stale catalog row: TASK 12 (master limiter) shipped 2026-08-15 and was still marked 'Queued'.
2.6 KiB
2.6 KiB
TASK 55 — Disk hygiene: log rotation + low-disk guard (queued 2026-10-09)
Catalog:
TASKS.md— status and requirements live here.
Why (creator ask, 2026-10-09): "we need some sort of log-rotation so that we don't inadvertently fill up a user's drive." A free app that quietly eats disk space is a support ticket and a trust breach.
What's known (from the 2026-10-09 privacy-policy code research — re-verify before building):
Helpers/AppLog.csappends to%APPDATA%\ytLlive\startup.log, a timestamped line per entry, with no size cap or rotation found (not specifically searched — confirm first).Services/Encoder/FfmpegEncoder.cs(~:371) logs every non-progress ffmpeg stderr line (≤400 chars each) — the main growth source over long streams.- Default alert clip is written to
%TEMP%\ytLive-alert-<id>.mp4(ViewModels/MainViewModel.Chat.cs~:106) — confirm whether it's ever deleted. - Recordings (
.mp4, defaultDownloads) are user-directed, but nothing checks free space.
Slices (one integration test each, in order):
- ✅ Size-capped log rotation — when
startup.logpasses a cap (~5 MB), roll it tostartup.1.log(keep 1–2 old files), start fresh. Test: write past the cap, assert the roll and the bounded total. Standard pattern (NLog/SerilogfileSizeLimitBytes+retainedFileCountLimit) — cite in the commit.- SHIPPED 2026-10-22.
Helpers/LogRotation.cs(new) holds the policy as a pure function over a path —RollIfNeeded(logPath, maxBytes, retainedFiles)shiftsname.1.log→name.2.log→ … and the live file →name.1.log, so the file set is bounded, not just the live file.AppLogcalls it before each append (cap 5 MB, 1 rolled copy) and keeps its 156-call-site surface unchanged; the test seams are twointernalproperties (PathOverride,MaxBytes) — the app project already hasInternalsVisibleTo("ytLive.Tests"). Guard:ytLive.Tests/AppLogRotationTests.cs(the ONE test: the log rolls at the cap, the live file starts fresh, and the directory still holds exactlystartup.log+startup.1.logafter a SECOND roll — the growth is bounded).
- SHIPPED 2026-10-22.
- ☐ Temp alert clip cleanup — delete the
%TEMP%alert clip on app close (and sweep stale ones at startup). Test: create, close, assert gone. - ☐ Low-disk guard for recordings — check free space on the record folder's drive before Record starts, and warn (toast) when it runs low mid-recording. Thresholds TBD with the creator.
Design decisions: keep AppLog's call surface unchanged — rotation lives inside it.