Fixes #5016 - Fix deadlock in EventIPCTransport.DispatchWailsEvent holding RLock during InvokeSync by wayneforrest · Pull Request #5107 · wailsapp/wails

wayneforrest · 2026-04-02T21:40:35Z

Description

Potential deadlock in EventIPCTransport.DispatchWailsEvent lock ordering issue.
See details in #5106

Type of change

Please select the option that is relevant.

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration using wails doctor.

Windows
macOS
Linux

If you checked Linux, please specify the distro and version.

Test Configuration

Please paste the output of wails doctor. If you are unable to run this command, please describe your environment in as much detail as possible.

Checklist:

I have updated website/src/pages/changelog.mdx with details of this PR
My code follows the general coding style of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes

Summary by CodeRabbit

Bug Fixes
- Resolved a deadlock during event dispatch that could block the app, improving stability.
- Stopped attempts to execute code on uninitialized or destroyed windows, reducing runtime errors and crashes.
Refactor
- Improved event dispatch responsiveness by snapshotting targets before sending events, while preserving cancellation behavior.

coderabbitai · 2026-04-02T21:40:58Z

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

@coderabbitai resume to resume automatic reviews.
@coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

▶️ Resume reviews
🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: add2a2d2-8929-4157-bef0-325e891dd64e

📥 Commits

Reviewing files that changed from the base of the PR and between 506d558 and b383c3b.

📒 Files selected for processing (1)

v3/UNRELEASED_CHANGELOG.md

✅ Files skipped from review due to trivial changes (1)

v3/UNRELEASED_CHANGELOG.md

Walkthrough

Dispatch now snapshots app.windows under app.windowsLock.RLock() and releases the lock before iterating and calling each window.DispatchWailsEvent(event). Separately, window dispatch now early-returns when the window implementation is nil or the window is destroyed.

Changes

Cohort / File(s)	Summary
IPC Event Dispatch `v3/pkg/application/transport_event_ipc.go`	Snapshot `app.windows` while holding `windowsLock.RLock()`, release the lock, then iterate the snapshot and call `DispatchWailsEvent`; cancellation checked per-iteration after snapshot.
Window dispatch guard `v3/pkg/application/webview_window.go`	`DispatchWailsEvent` now returns early if `w.impl` is `nil` or `w.isDestroyed()` to avoid `ExecJS` during teardown/race.
Changelog `v3/UNRELEASED_CHANGELOG.md`	Adds a Fixed changelog entry describing the deadlock fix for `EventIPCTransport.DispatchWailsEvent` (holding `RLock` during `InvokeSync`).

Sequence Diagram(s)

sequenceDiagram
  participant App as App
  participant Lock as windowsLock
  participant Snapshot as windows (slice)
  participant Window as Window
  App->>Lock: RLock()
  Lock-->>App: copy app.windows -> Snapshot
  App->>Lock: RUnlock()
  loop for each window in Snapshot
    App->>Window: DispatchWailsEvent(event)
    Window-->>App: InvokeSync / response (may block)
    alt event.IsCancelled()
      App->>App: break loop
    end
  end

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related issues

[wails3] deadlock - wails v3 alpha.74 #5106: Implements snapshot-and-release of app.windows to avoid holding windowsLock while calling DispatchWailsEvent/InvokeSync, addressing the deadlock described.

Possibly related PRs

fix(v3): guard dispatchWailsEvent against race condition on reload #4925: Adds runtime/window readiness guards for event dispatch in webview_window.go (related guard changes).
[wails3] deadlock - wails v3 alpha.74 #5106: Related upstream discussion/fix for deadlock when holding locks during synchronous invokes.

Suggested labels

Bug, MacOS, v3-alpha, go, size:M, v3

Suggested reviewers

leaanthony

Poem

🐰 I nudged the lock and hopped away,
Events now travel out to play.
No freezes, blocks, or tangled thread,
Just gentle hops from bed to bed. ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main deadlock fix in EventIPCTransport.DispatchWailsEvent, clearly summarizing the primary change addressing lock ordering issues.
Description check	✅ Passed	The description follows the template with the bug fix type selected, references the related issue (`#5106`), and specifies macOS testing. However, test configuration details and most checklist items remain uncompleted.
Linked Issues check	✅ Passed	The PR addresses the deadlock in EventIPCTransport.DispatchWailsEvent (`#5106`) and restores frameless window minimization on macOS (`#5016`), meeting the core coding objectives despite incomplete checklist items.
Out of Scope Changes check	✅ Passed	The three file changes (transport_event_ipc.go, webview_window.go, changelog) are directly scoped to fixing the deadlock and preventing window dispatch crashes, with no unrelated alterations detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

🧹 Nitpick comments (1)

v3/pkg/application/transport_event_ipc.go (1)

22-27: Please add a regression test for lock inversion deadlock.

This path is concurrency-sensitive; a targeted test that dispatches while windows are added/removed would help prevent regressions.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@v3/pkg/application/transport_event_ipc.go` around lines 22 - 27, Add a
concurrent regression test that reproduces the lock-inversion scenario by
repeatedly calling DispatchWailsEvent while other goroutines concurrently
add/remove entries from the windows collection; specifically create a test
(e.g., TestDispatchWhileModifyingWindows) that spins up one goroutine to loop
window.DispatchWailsEvent(event) and another to concurrently add and remove
windows, coordinate start/stop with sync.WaitGroup or channels, enforce a
timeout/context deadline to fail the test on deadlock, and assert progress
(e.g., event delivered or loop iterations completed) to detect hangs; target the
code paths around windows, DispatchWailsEvent and event.IsCancelled to ensure
the concurrency-sensitive path is covered under the race detector.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@v3/pkg/application/transport_event_ipc.go`:
- Around line 22-27: Add a concurrent regression test that reproduces the
lock-inversion scenario by repeatedly calling DispatchWailsEvent while other
goroutines concurrently add/remove entries from the windows collection;
specifically create a test (e.g., TestDispatchWhileModifyingWindows) that spins
up one goroutine to loop window.DispatchWailsEvent(event) and another to
concurrently add and remove windows, coordinate start/stop with sync.WaitGroup
or channels, enforce a timeout/context deadline to fail the test on deadlock,
and assert progress (e.g., event delivered or loop iterations completed) to
detect hangs; target the code paths around windows, DispatchWailsEvent and
event.IsCancelled to ensure the concurrency-sensitive path is covered under the
race detector.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 2e8d59ec-2082-44c3-99d0-7767a809b2cd

📥 Commits

Reviewing files that changed from the base of the PR and between bb4fbf9 and 838b00a.

📒 Files selected for processing (1)

v3/pkg/application/transport_event_ipc.go

leaanthony · 2026-04-14T21:28:26Z

Thanks for opening this. This introduces a small and unlikely race condition if the window gets deleted after the copy but before the dispatch, the application will crash. that was likely the intent of having a lock there in the first place. There is other code in Window that checks if it is being destroyed. It would be good to follow that pattern here to prevent crashes

leaanthony · 2026-04-15T10:01:19Z

Here is an example: https://github.com/wailsapp/wails/blob/v3-alpha/v3/pkg/application/webview_window_darwin.go#L1639

…ring InvokeSync

wayneforrest · 2026-04-15T21:16:44Z

Here is an example: https://github.com/wailsapp/wails/blob/v3-alpha/v3/pkg/application/webview_window_darwin.go#L1639

Morning @leaanthony -- I have added one more commit: 506d558

It guards against dispatching events when the window has been destroyed.

leaanthony · 2026-04-16T12:05:23Z

Thanks for doing this 🙏

Addresses issues that could cause menu buttons to stop responding when events are emitted frequently: Fix race condition in mainthread callback store (Linux, macOS, iOS): - Change RLock() to Lock() when deleting from mainThreadFunctionStore. Using RLock for the read but then calling delete() violated the RWMutex contract and could cause undefined behaviour under concurrent access. The related EventIPCTransport.DispatchWailsEvent deadlock identified during this investigation was independently fixed on master in #5107. Adds regression tests and a manual reproduction app under v3/test/4424-event-block/.

* fix(linux): fix race conditions in mainthread event handling (#4424) Addresses issues that could cause menu buttons to stop responding when events are emitted frequently: Fix race condition in mainthread callback store (Linux, macOS, iOS): - Change RLock() to Lock() when deleting from mainThreadFunctionStore. Using RLock for the read but then calling delete() violated the RWMutex contract and could cause undefined behaviour under concurrent access. The related EventIPCTransport.DispatchWailsEvent deadlock identified during this investigation was independently fixed on master in #5107. Adds regression tests and a manual reproduction app under v3/test/4424-event-block/. * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix(v3): address Copilot review on #5192 - mainthread_android.go: apply the same RLock -> Lock change made to the linux/macOS/iOS callback paths. Android uses the same shared mainThreadFunctionStore, so it had the identical map-write under RLock pattern. - transport_event_ipc_test: the previous lock-release test used an empty windows map and so would also have passed against the broken (lock-held-across-dispatch) implementation. Replace it with a probe Window whose DispatchWailsEvent attempts windowsLock.TryLock(); the fixed snapshot-and-release path lets the TryLock succeed, a regression to holding RLock across per-window dispatch fails it. Verified by mutation-test against the regressed implementation. - test/4424-event-block: the manual repro had no webview window and so EventIPCTransport.DispatchWailsEvent's per-window loop was a no-op, making the harness unable to reach the ExecJS path involved in #4424. Add a small webview window that subscribes to the emitted event, bump the emit cadence to 100ms so menu clicks have a high probability of landing during a dispatch, and document the manual pass/fail criteria in the file header. --------- Co-authored-by: Wails Documentation Agent <agent@wails.local> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

coderabbitai Bot reviewed Apr 2, 2026

View reviewed changes

wayneforrest added 3 commits April 16, 2026 08:46

Fix deadlock in EventIPCTransport.DispatchWailsEvent holding RLock du…

91496fd

…ring InvokeSync

Update changelog

5f04b19

Guard WebviewWindow.DispatchWailsEvent against destroyed windows

506d558

wayneforrest force-pushed the fix-dead-lock-ipc-dispatch branch from 87bbd19 to 506d558 Compare April 15, 2026 21:14

leaanthony approved these changes Apr 15, 2026

View reviewed changes

Merge branch 'v3-alpha' into fix-dead-lock-ipc-dispatch

b383c3b

leaanthony enabled auto-merge (squash) April 16, 2026 11:18

leaanthony merged commit 5aa71e1 into wailsapp:v3-alpha Apr 16, 2026
44 of 45 checks passed

leaanthony mentioned this pull request May 6, 2026

[wails3] deadlock - wails v3 alpha.74 #5106

Closed

coderabbitai Bot mentioned this pull request May 17, 2026

fix(linux): fix race conditions and deadlocks in event handling #5192

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fixes #5016 - Fix deadlock in EventIPCTransport.DispatchWailsEvent holding RLock during InvokeSync#5107

Fixes #5016 - Fix deadlock in EventIPCTransport.DispatchWailsEvent holding RLock during InvokeSync#5107
leaanthony merged 4 commits into
wailsapp:v3-alphafrom
wayneforrest:fix-dead-lock-ipc-dispatch

wayneforrest commented Apr 2, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Apr 2, 2026 •

edited

Loading

Reviews paused

Uh oh!

coderabbitai Bot left a comment

Uh oh!

leaanthony commented Apr 14, 2026 •

edited

Loading

Uh oh!

leaanthony commented Apr 15, 2026

Uh oh!

wayneforrest commented Apr 15, 2026

Uh oh!

Uh oh!

leaanthony commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

wayneforrest commented Apr 2, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of change

How Has This Been Tested?

Test Configuration

Checklist:

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviews paused

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Possibly related issues

Possibly related PRs

Suggested labels

Suggested reviewers

Poem

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

leaanthony commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

leaanthony commented Apr 15, 2026

Uh oh!

wayneforrest commented Apr 15, 2026

Uh oh!

Uh oh!

leaanthony commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

wayneforrest commented Apr 2, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Apr 2, 2026 •

edited

Loading

leaanthony commented Apr 14, 2026 •

edited

Loading