Fix stale state in callbacks when multiple events fire rapidly#3988
Merged
Madoshakalaka merged 1 commit intomasterfrom Feb 16, 2026
Merged
Fix stale state in callbacks when multiple events fire rapidly#3988Madoshakalaka merged 1 commit intomasterfrom
Madoshakalaka merged 1 commit intomasterfrom
Conversation
UseReducerHandle previously cached a single Rc<T> snapshot at render time. When dispatch updated the shared RefCell, callback closures still held handles pointing to the old snapshot, causing stale reads. Replace the snapshot with a deref_history approach: Deref now clones the latest Rc<T> from the shared RefCell and accumulates it in a Vec so that returned references remain valid for the handle's lifetime. The history is deduplicated by Rc::ptr_eq to avoid growth from repeated reads and is reset on each re-render when a new handle is created. This avoids the unsound pattern from PR #3963, where the Ref guard from try_borrow() was dropped while a pointer derived from it was returned. That caused use-after-free when dispatch replaced the Rc (refcount 1) and the allocator reused the freed memory. A dedicated test exercises this exact sequence and confirms it no longer corrupts memory. Fixes #3796 Supersedes #3963
|
Visit the preview URL for this PR (updated for commit 0eda3a8): https://yew-rs-api--pr3988-fix-stale-state-issu-0xcma3oj.web.app (expires Mon, 23 Feb 2026 06:10:35 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Benchmark - coreYew MasterPull Request |
Benchmark - SSRYew MasterDetails
Pull RequestDetails
|
Size ComparisonDetails
|
Madoshakalaka
force-pushed
the
fix/stale-state-issue-3796-v2
branch
from
ee9cd41 to
0eda3a8
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
UseReducerHandle previously cached a single Rc snapshot at render time. When dispatch updated the shared RefCell, callback closures still held handles pointing to the old snapshot, causing stale reads.
Replace the snapshot with a deref_history approach: Deref now clones the latest Rc from the shared RefCell and accumulates it in a Vec so that returned references remain valid for the handle's lifetime. The history is deduplicated by Rc::ptr_eq to avoid growth from repeated reads and is reset on each re-render when a new handle is created.
This avoids the unsound pattern from PR #3963, where the Ref guard from try_borrow() was dropped while a pointer derived from it was returned. That caused use-after-free when dispatch replaced the Rc (refcount 1) and the allocator reused the freed memory. A dedicated test exercises this exact sequence and confirms it no longer corrupts memory.
Fixes #3796
Supersedes #3963
Fixes #0000
Checklist
(a test for the issue, and a test the old PR #3963 fails on)