Skip to content

gpui: fix stale cached layout nodes after element path changes - #52

Merged
huacnlee merged 1 commit into
mainfrom
fix/issue-3408-cached-layout
Oct 9, 2026
Merged

huacnlee merged 1 commit into
mainfrom
fix/issue-3408-cached-layout

Conversation

@huacnlee

@huacnlee huacnlee commented Oct 9, 2026

Copy link
Copy Markdown
Member

A clean cached view can reuse paint after an anonymous wrapper is added or removed, but its retained record still copied the previous layout root. Once that node was released, a subsequent child notification made layout_reaches panic with invalid SlotMap key used, as reported in longbridge/gpui-kit#3408 (comment).

Refresh the reused view record with the layout requested this frame and its current rebuild context. Paint remains cached, while future splices use the current layout node and element path.

Regression tests cover adding, removing, and keeping the wrapper, followed by repeated child updates. They verify cached paint reuse, consistent rebuild paths, and frame output matching retention disabled. Before the fix, both shape-change scenarios reproduce the SlotMap panic.

Validation:

  • cargo test -p gpui --lib fast::tests:: -- --nocapture: 233 passed, 1 ignored.
  • cargo clippy -p gpui --lib --tests -- -D warnings: passed.
  • script/check-upstream: passed.
  • git diff --check: passed.

@huacnlee
huacnlee merged commit c4b8873 into main Oct 9, 2026
4 checks passed
@huacnlee
huacnlee deleted the fix/issue-3408-cached-layout branch October 9, 2026 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant