ExecutionStore.add() calls persist() on every insert, and persist() writes the whole array:
private async persist(): Promise<void> {
await this.context.workspaceState.update(STORAGE_KEY, this.executions);
}
Each entry carries its full captured output, so with the defaults (maxEntries 50, maxOutputBytes 102400) a full history is up to roughly 5 MB. That entire structure is re-serialized and written to the workspace state database after every single terminal command, including a one-line echo that produced 12 bytes of output.
It works, and nothing is lost. The cost is that the write scales with the whole history rather than with the new entry, and it lands on a path that runs constantly while you work, which is a bit at odds with an extension whose selling point is that it sits quietly behind every command you run.
Worth considering, in rough order of how much they change:
- Debounce
persist(). History surviving a reload does not require the write to be synchronous with the command that triggered it.
- Persist output up to a smaller cap than the in-memory one, and keep the full text only for the current session. Reload fidelity for a 100 KB dump is a much weaker requirement than having it while the window is open.
- Cap total persisted bytes across all entries, not just per command, so the worst case is bounded by something other than
maxEntries * maxOutputBytes.
Happy to send a PR for whichever direction you prefer, since which of these is right depends on how much you care about full output surviving a reload.
ExecutionStore.add()callspersist()on every insert, andpersist()writes the whole array:Each entry carries its full captured
output, so with the defaults (maxEntries50,maxOutputBytes102400) a full history is up to roughly 5 MB. That entire structure is re-serialized and written to the workspace state database after every single terminal command, including a one-lineechothat produced 12 bytes of output.It works, and nothing is lost. The cost is that the write scales with the whole history rather than with the new entry, and it lands on a path that runs constantly while you work, which is a bit at odds with an extension whose selling point is that it sits quietly behind every command you run.
Worth considering, in rough order of how much they change:
persist(). History surviving a reload does not require the write to be synchronous with the command that triggered it.maxEntries * maxOutputBytes.Happy to send a PR for whichever direction you prefer, since which of these is right depends on how much you care about full output surviving a reload.