Skip to content

Fix panic in resolve_stylist when animation entry is stale#408

Open
yes1688 wants to merge 1 commit intoDioxusLabs:mainfrom
yes1688:fix/resolve-stylist-stale-slab-key
Open

Fix panic in resolve_stylist when animation entry is stale#408
yes1688 wants to merge 1 commit intoDioxusLabs:mainfrom
yes1688:fix/resolve-stylist-stale-slab-key

Conversation

@yes1688
Copy link
Copy Markdown

@yes1688 yes1688 commented Apr 28, 2026

Summary

Fixes #407 — panic with "invalid key" in resolve_stylist when an animation
entry's Slab key is stale after node removal.

Change

1-line fix using get_mut to skip stale entries safely:

let Some(node) = self.nodes.get_mut(node_id) else {
    continue; // stale animation entry — node removed from slab
};
node.set_restyle_hint(RestyleHint::RESTYLE_SELF);

Verification

Notes

If you'd prefer a different approach (e.g. cleaning up animations.sets on node
removal at the source), happy to rework — just let me know your preference.


Drafted with Claude, fix and reproduction hand-verified.

When `traverse_dom` writes node_ids into `animations.sets` during the first
resolve, a subsequent removal of the animated node can leave a stale Slab key.
The next resolve panics with "invalid key" on direct `self.nodes[node_id]`
indexing.

Fix: use `get_mut` and skip stale entries with `continue`.

Repro: see DioxusLabs#407
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.

Panic in resolve_stylist: "invalid key" when animation node tracked but removed

1 participant