fix(opener): avoid blocking-runtime panic in reveal_item_in_dir - #3565
Open
cyclone-mind wants to merge 1 commit into
Open
cyclone-mind wants to merge 1 commit into
cyclone-mind wants to merge 1 commit into
Conversation
Contributor
Package Changes Through 8022336There are 2 changes which include opener with patch, opener-js with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
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.
On Linux,
reveal_items_in_diropens a blocking zbus connection(
zbus::blocking::Connection::session()). Thereveal_item_in_dircommand runsthat synchronously on the async runtime's worker thread, which panics with
"Cannot start a runtime from within a runtime" — the JS promise then just hangs,
no rejection ever reaches the frontend.
Wrapped the call in
tauri::async_runtime::spawn_blockingso it runs off theasync worker thread. Same fix the issue reporter already confirmed works as an
app-side workaround, just moved into the plugin so nobody has to hand-roll it.
Fixes #3552
Verified with
cargo check/cargo fmt --check/cargo clippyon the openercrate — all clean. Don't have a Linux box handy to reproduce the actual panic,
but the change is a direct port of the reporter's verified workaround.
Added a
.changesentry per the repo's covector convention.