Reload from Disk vs. Invalidate Caches: Which Cache Layer Must Be Rebuilt After External Go Code Generation?

After running go generate, switching git branches, or letting mock generators rewrite files externally, GoLand can continue serving stale symbol resolution and completion. The cheap path, File | Reload All from Disk, re-reads file bytes and updates the virtual file system, but it does not rebuild symbol indexes, so unresolved-reference diagnostics may persist. The expensive path, File | Invalidate Caches / Restart, discards VFS and index caches and forces a full reindex, but it costs time on large Go monorepos and discards unsaved in-memory changes. Automatic invalidation depends on file-system watchers and sync settings, which can miss atomic-rename writes or network shares, and Go module state may remain stale after an external go mod tidy.

Given that no documented, deterministic guarantee exists that an external tool's write is detected, which refresh scope should a team standardize on when correctness matters more than IDE responsiveness? Is there a middle-ground configuration of synchronization settings or module reload triggers that avoids full reindexing while ensuring generated symbols resolve? How can the limits of file-watcher events be verified on the installed GoLand build before choosing a policy?