You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem observed after the initial P0 rename fixes:
363
+
364
+
-`rename` can modify unopened files, but server-side caches for those files were not explicitly invalidated in the rename request path.
365
+
-`RenameFeature` also queued async reindex work before client-side workspace edits were guaranteed to be applied, which could create short-lived stale index/range behavior.
- Adjusted `InMemoryDocumentStore.removeFile()` semantics to match production `DocumentStore.removeFile()` behavior (clear retrieved-file cache semantics instead of deleting open documents)
- Repro fixture created in local filesystem (`/tmp/bean-rename-fsa-case`) with:
388
+
-`main.bean`
389
+
-`a.bean`
390
+
-`b.bean`
391
+
- Verified scenario:
392
+
1. Open `a.bean` only (keep `b.bean` unopened)
393
+
2. Rename `Assets:Cash` -> `Assets:Cash:Wallet`
394
+
3. Confirmed browser reports `Made 4 text edits in 2 files`
395
+
4. Confirmed unopened `b.bean` content was updated on disk
396
+
5. Opened `b.bean`, invoked `F2` on renamed token, prepare-rename succeeded
397
+
6. Renamed back `Assets:Cash:Wallet` -> `Assets:Cash`
398
+
7. Confirmed both files reverted correctly on disk
399
+
400
+
Validation outcome:
401
+
402
+
- Cross-file rename on unopened documents works in playground FSA mode.
403
+
- No obvious prepare-rename position mismatch was observed on the renamed token after opening `b.bean`.
404
+
-`Find References` in this playground repro did not produce usable baseline results (`No references found`), so this iteration did **not** validate post-rename reference-location accuracy in browser UI.
405
+
406
+
Reviewer note:
407
+
408
+
- During reverse rename, an editor-side list item (outline/symbol-like UI) briefly appeared stale while on-disk file contents were already correct. This may be a UI refresh lag rather than AST/range corruption, but it remains a good follow-up target if position issues are reported again.
0 commit comments