Reload .autocp when modified externally#170
Open
znzryb wants to merge 2 commits into
Open
Conversation
Previously .autocp was loaded once via `by lazy` and only written to, so any external edit (e.g. by an AI tool) would be silently overwritten by AutoCpStorageSaver on the next saveAllDocuments using stale in-memory state. Register a BulkFileListener that calls AutoCpStorage.reloadFromDisk() when the file's content changes on disk, re-parsing through the existing Migrations path and resetting the two MutableStateFlows. The saver also short-circuits when document text already matches the encoded db, preventing a write-fire-reload loop and avoiding spurious modify events. The IDE-internal warning panel (AutoCpFileEditor) is unchanged -- direct edits inside the IDE editor remain blocked.
When an external tool (e.g. an AI script generating problem sets) writes a fresh .autocp into a project directory that previously had none, the user's data disappears within seconds: the file shows up with only a stub SolutionFile entry, all problems gone. Mechanism: AutoCpStorage's databaseDelegate is `by lazy`, so on first access (tool window opening, a cpp file getting focus) it sees no .autocp on disk and initializes to AutoCpDB() default. The external write then arrives as VFileCreateEvent, but AutoCpExternalReloader filtered only VFileContentChangeEvent, so reloadFromDisk() never ran and in-memory stayed at the empty default. Any subsequent beforeAllDocumentsSaving (triggered by focus changes / doc saves) serialized that empty default and overwrote the disk content. If the user clicked an unassociated .cpp in between, ToolFactory's AssociateFilePanel injected a stub SolutionFile, which is what ended up on disk in place of the original data. Widen the listener filter to also accept VFileCreateEvent so the created file is parsed into memory before any save fires. Add a staleness guard in AutoCpStorageSaver: if in-memory equals DEFAULT_AUTO_CP_DB but the disk document is non-blank, reload from disk instead of overwriting it -- covers the theoretical race where beforeAllDocumentsSaving lands ahead of the BulkFileListener dispatch.
|
Codecov Report❌ Patch coverage is
🚀 New features to boost your workflow:
|
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
2 participants
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.
Motivation
.autocpis loaded once viaby lazyand only ever written to, so any external edit (a script, another editor, an AI tool) gets silently overwritten byAutoCpStorageSaveron the nextsaveAllDocumentsusing stale in-memory state.Change
Register a
BulkFileListener(application level) that calls a newAutoCpStorage.reloadFromDisk()whenever a file named.autocpunder any open project'sbasePathreports a content change. It re-parses through the existingMigrationspath and resets the twoMutableStateFlows.The saver also short-circuits with
if (document.text == newText) returnbeforesetText, which prevents a write→fire→reload loop and avoids spurious modify events.The IDE-internal warning panel in
AutoCpFileEditoris unchanged — direct editing inside the IDE remains blocked viaHIDE_DEFAULT_EDITOR.Failure mode
If the new disk content fails to parse (invalid JSON / schema mismatch),
reloadFromDiskcatches andlog.warns, leaving in-memory state untouched — the nextsaveAllDocumentswill overwrite the broken file with the previous valid state, equivalent to the current "external edit silently lost" behaviour. No data loss compared to the status quo.