Refresh an open output tab when its execution leaves history - #26
Open
Chirag6722 wants to merge 1 commit into
Open
Refresh an open output tab when its execution leaves history#26Chirag6722 wants to merge 1 commit into
Chirag6722 wants to merge 1 commit into
Conversation
Fixes thegoodengineer#3 OutputFileSystemProvider declared _onDidChangeFile and never fired it, so VS Code had no reason to call readFile again. An output tab left open across Clear History, or across a maxEntries trim, kept rendering an execution that was no longer there. readFile already answers for a missing id with "no longer in history (history was cleared or trimmed)". It just never got asked. Track the ids actually served, and on store change fire for any that have since left. Changed rather than Deleted on purpose: the tab re-reads and displays that explanation, instead of the editor being closed under someone who was mid-read. Explaining the absence is the same stance the rest of the codebase takes. The served set stays bounded, since an id is dropped as soon as it leaves the store and is otherwise capped by maxEntries. Verified end to end: open a tab on a recorded execution, clear history, and the same document now reads TruthLog: execution "..." is no longer in history (history was cleared or trimmed). Co-Authored-By: Claude Opus 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
1 participant
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.
Fixes #3, per your direction: fire from
store.onDidChangefor the affected ids.OutputFileSystemProviderdeclared_onDidChangeFileand never fired it, so VS Code had no reason to callreadFileagain. A tab left open across Clear History, or across amaxEntriestrim, kept rendering an execution that was gone.readFilealready answers for a missing id with "no longer in history (history was cleared or trimmed)". It just never got asked.Now the provider tracks the ids it has actually served and, on store change, fires for any that have since left. The set stays bounded: an id is dropped as soon as it leaves the store, and is otherwise capped by
maxEntries.One judgment call I made, easy to reverse if you disagree. I fire
Changedrather thanDeleted.Deletedwould close the editor out from under someone mid-read;Changedmakes the tab re-read and show the explanation that was already written for this exact case. Explaining the absence rather than making it disappear seemed like the same stance the codebase already takes with disabled shell integration and cmd.exe.A recorded execution never changes once stored, so removal is the only content change that can happen. That is why this fires only for departures rather than for every store change.
Verified end to end rather than by inspection: open a tab on a recorded execution, clear history, and the same document object now reads
49 passing on Windows, including the new test.