fix(desktop): preserve edits across websocket reconnects - #5812
Open
nl310 wants to merge 1 commit into
Open
Conversation
nl310
marked this pull request as ready for review
September 5, 2026 09:54
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
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.
A webview that reconnects while its previous edits worker is idle can stop receiving UI updates. The old worker is still registered as
Connected;handle_connectionremoves that entry and rejects the replacement. A transport regression against unmodifiedmain(74a4973) reproduces this withProtocol(ResetWithoutClosingHandshake)after the first successful edit and ACK.This follows up on #4391 and the iOS suspension report in #4374. The affected connection logic is also present in 0.7.10 and v0.8.0-alpha.1. This PR targets current
main.Change
The JavaScript changes are in
NativeInterpreter.waitForRequest; the existing LiveView edit helpers are unchanged. This does not reload the page or recreate application state.Reproduction and validation
The failing baseline test opens a queue, sends and acknowledges an edit, drops the idle socket, reconnects, and attempts another edit. It fails on unmodified
main; the regression now passes with the replacement transport.Validated locally on macOS with Rust 1.98.0:
cargo test -p dioxus-desktop --lib— 7 passed, including 5 socket regressions for idle reconnect, unacknowledged replay, repeated handovers, listener/key rotation, and invalid client keys.node --test packages/interpreter/tests/native_reconnect.cjs— 5 passed. These load the generated native interpreter and exercise deferred rendering, lost ACKs, stale sockets/timers, automatic reconnect, and server authentication.cargo check -p dioxus-desktop --lib --target aarch64-apple-ios— passed.cargo clippy -p dioxus-desktop --lib --tests --no-deps -- -D warnings— passed.git diff --check— passed.The reconnect tests are added to the existing macOS/Linux Playwright CI jobs. An initial Clippy run including workspace dependencies stopped on existing
dioxus-core-macroformatting-borrow lints under Rust 1.98.0; no unrelated code was changed. The full workspace test suite was not run.Remaining validation
Draft pending maintainer feedback on the private transport change and physical-iPhone validation. The socket and JavaScript harnesses reproduce the transport failures but do not simulate all WKWebView or OS suspension behavior. On a physical device, background or lock a small counter app for several minutes, resume and interact, and repeat both while idle and while an update is pending. An application with an open input dialog should also retain its draft through resume.