fix: stale envFrameMap#3932
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThis PR adds frame map clearing capability to the CSE machine layout system. The ChangesFrame map clearing during layout initialization
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request introduces a static clearMap method to the Frame component to clear the environment frame map, and integrates this call during the grid initialization in CseMachineLayout. The reviewer suggested updating the relative import of Frame to an absolute import starting with src/ to align with the repository's import guidelines.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Description
Closes #3127
Frame.envFrameMap is a static Map<string, Frame> that maps environment IDs to their rendered Frame objects. It was never cleared between steps, so stale Frame objects from previous render passes persisted in the map.
The symptom: FnValue.draw() calls Frame.getFrom(this.data.environment) to find the enclosing frame and draw an arrow to it. This lookup returned a Frame from an earlier step — one that applyFixedPositions() had never updated. The stale frame had its original computed _y (e.g. 215) while the current layout's frame had the correct cached _y (e.g. 240) after applyFixedPositions ran. So enclosingFrame pointed to a ghost frame at the wrong position, not the live one in the current layout.
Fix: call Frame.clearMap() at the top of initializeGrid() so the map is wiped before new Frame objects are registered for the current step. After this, FnValue.draw() always resolves enclosingFrame to the current step's Frame, which has had its coordinates correctly updated by applyFixedPositions.
Refer to the comment section here for how the debugging happened and a clearer understanding on what the bug actually is and what the cause of it actually is.
Type of change
How to test
To test and see how to use the Chrome dev tools along with the breakpoints feature, refer to the actual issue at #3127.
Checklist