extension.ts keeps every line it has ever logged:
const logLines: string[] = [];
function log(message: string): void {
const line = `[${new Date().toISOString()}] ${message}`;
logLines.push(line);
outputChannel?.appendLine(line);
}
Two small things follow from that.
It is unbounded. There is one END command=... line per recorded command, and each embeds the full command text via JSON.stringify, so the array grows for as long as the window is open. maxEntries bounds the history but not this. Nothing dramatic at a realistic command rate, but it is the one structure in the extension with no ceiling, in a codebase that is otherwise careful to put a cap on things.
It is also module state that deactivate() does not reset, while outputChannel is. If the extension host reactivates in the same process, the new session starts with the previous session's lines already in the array, and getLogLines() (which the tests read, some of them by slicing from a recorded offset) returns both sessions mixed together.
Capping it as a ring buffer of the last N lines and clearing it in deactivate() would settle both. The array exists for the tests, since VS Code has no API for reading an OutputChannel back, so a cap needs to stay comfortably above what any single test inspects.
extension.tskeeps every line it has ever logged:Two small things follow from that.
It is unbounded. There is one
END command=...line per recorded command, and each embeds the full command text viaJSON.stringify, so the array grows for as long as the window is open.maxEntriesbounds the history but not this. Nothing dramatic at a realistic command rate, but it is the one structure in the extension with no ceiling, in a codebase that is otherwise careful to put a cap on things.It is also module state that
deactivate()does not reset, whileoutputChannelis. If the extension host reactivates in the same process, the new session starts with the previous session's lines already in the array, andgetLogLines()(which the tests read, some of them by slicing from a recorded offset) returns both sessions mixed together.Capping it as a ring buffer of the last N lines and clearing it in
deactivate()would settle both. The array exists for the tests, since VS Code has no API for reading an OutputChannel back, so a cap needs to stay comfortably above what any single test inspects.