Repository navigation
Lot 17: a log that turns over each day, and a purge that leaves nothing - #18
Merged
Merged
Conversation
The log was one file for ever. It is now one file a day, gamemode-executor.YYYY-MM-DD.log, written through tracing-appender's RollingFileAppender, synchronously as before, and the last log_days of them are kept: a new key, optional, 7 when absent, a whole number of 1 or more. The day is UTC's, the library offering no other; the lines keep local time. A spike came first, the maintainer's condition: a turnover that needed a restart would have ruled the library out. It does not. The appender checks at every write and opens the next file itself, the minutely rotation running the daily one's code; one long writer and two short ones across two minute boundaries kept every line whole. It also showed every process pruning when it builds its appender, one below its maximum, so max_log_files is log_days + 1. presence-probe log-turnover replays it with the program's own appender. What the library now does is gone from our code: the file opened by hand into a Mutex, LOG_FILE_NAME and the one-file assumption in the tray, the service and purge, and the hand-made local timestamp, now tracing-subscriber's LocalTime, whose local-offset caveat is Unix's. Open log opens the file written last; purge removes every log file; log_days, like log_dir, waits for the next start and says so. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
purge removes an installed copy through msiexec /x once it has exited, and the package's uninstall runs stop and uninstall-task, which log what they did -- to the default folder, the configuration being gone. So a log file and its folders came back after every purge of an installed copy. The shell purge leaves behind now waits for msiexec, then deletes the log files there and the folders that leaves empty. The maintainer chose this over a flag keeping those commands off the file, which would have changed the package and two setup commands. Testing it through the real shell showed purge relying on Remove-Item without -Recurse to keep a folder that holds something: a non-interactive shell turns the prompt into an error and exits with 1. Both uses now ask whether the folder is empty first. The maintainer's real purge on 2026-09-26 then left %LOCALAPPDATA%\GameModeExecutor behind for another reason: the updater's folder, which an update empties and never removes, and which purge did not know. Nothing else writes there, so purge now takes it whole, its path from update::updates_dir, the one place that names it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every rule kept, a third fewer words: the anecdotes behind them are in the design record. Four rules that lived only in an agent's private memory join it, since any agent working here should follow them: user pages short with the detail in docs/design, words in their exact sense, say who saw a verification, and the Remove-Item pitfall found in Lot 17. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lot 17: the log turns over each day. Field-verified on the maintainer's machine, and closed.
tracingout. It does not.tracing-appenderchecks at every write and opens the next file itself; its minutely rotation runs the daily one's code. One long writer and two short ones crossed two minute boundaries with every line whole. The spike also showed that every process prunes when it builds its appender, somax_log_files = log_days + 1.presence-probe log-turnoverreplays it with the program's own appender.gamemode-executor.YYYY-MM-DD.log, written synchronously as before.log_days(optional, 7 by default, a whole number of 1 or more) says how many files are kept.purgeremoves them all, and the old single file is pruned as the oldest.Mutex;LOG_FILE_NAMEand the one-file assumption in the tray, the service andpurge;tracing-subscriber'sLocalTime, checked on Windows (its caveat is Unix's);purgeleaves nothing behind:stopanduninstall-task, which log what they did; their lines are now swept oncemsiexechas finished.updates, is now removed too; it is emptied but never deleted, and kept%LOCALAPPDATA%\GameModeExecutoralive.Remove-Itemfailing: in a non-interactive shell it exits with 1 on a non-empty folder.Seen in the field, 2026-09-25/26:
purgeof the installed copy, then the reinstall:initandinstall-taskwrote into the day's file.update --checkwrote into the day's file.Left to see:
updatesgone at the next real purge.build.ps1 testOK locally, 220 tests.🤖 Generated with Claude Code