[bug] PostMessage failed ; is the messages queue full?

[Fly-Potato]

Describe the bug

PanicInfo { payload: Any { .. }, message: Some(PostMessage failed ; is the messages queue full?), location: Location { file: "C:\Users\Potato\.cargo\registry\src\mirrors.aliyun.com-8754fae0eb2f08f1\wry-0.41.0\src\webview2\mod.rs", line: 974, col: 5 }, can_unwind: true, force_no_backtrace: false }

Reproduction

No response

Expected behavior

No response

Full tauri info output

[✔] Environment
    - OS: Windows 10.0.26100 X64
    ✔ WebView2: 126.0.2592.113
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.80.0 (051478957 2024-07-21)
    ✔ cargo: 1.80.0 (376290515 2024-07-16)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.12.0
    - pnpm: 9.1.3
    - yarn: 1.22.22
    - npm: 10.8.2

[-] Packages
    - tauri [RUST]: 2.0.0-rc.1
    - tauri-build [RUST]: 2.0.0-rc.1
    - wry [RUST]: 0.41.0
    - tao [RUST]: 0.28.1
    - @tauri-apps/api [NPM]: 2.0.0-rc.0
    - @tauri-apps/cli [NPM]: 2.0.0-rc.2

[-] App
    - build-type: bundle
    - CSP: img-src 'self' asset: http://asset.localhost blob: data:; style-src 'unsafe-inline' 'self' asset: http://asset.localhost blob: data:; connect-src ipc: http://ipc.localhost; default-src 'self'; media-src 'self' asset: http://asset.localhost blob: data:
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite

Stack trace

No response

Additional context

No response

[Fly-Potato]

What is this problem?

[Fly-Potato]

This problem often occurs

[FabianLars]

Do you have a minimal reproduction example for us? If not, something not-minimal is okay too, but we need something to work on since you're the first one to report this.

[Fly-Potato]

This issue mostly occurs when using tauri SQL and http plugins, But the frequency of occurrence is very low, Is it because the interaction between JS and Rust is too frequent?

[Fly-Potato]

PanicInfo { payload: Any { .. }, message: Some(called Result::unwrap() on an Err value: OsError { line: 1094, file: "C:\Users\Potato\.cargo\registry\src\index.crates.io-6f17d22bba15001f\tao-0.28.1\src\platform_impl\windows\window.rs", error: IoError(Os { code: 1400, kind: Uncategorized, message: "无效的窗口句柄。" }) }), location: Location { file: "C:\Users\Potato\.cargo\registry\src\index.crates.io-6f17d22bba15001f\tauri-runtime-wry-2.0.0-rc.2\src/lib.rs", line: 3755, col: 55 }, can_unwind: true, force_no_backtrace: false }

the new error

[greenhat616]

Same issue here. It should be occurred frequentlly while close window in dev mode.

Any solutions could be shared here?

[Fly-Potato]

I haven't found any solution

[Fly-Potato]

10893

[greenhat616]

@FabianLars Maybe we could modify the the assert! to log::error!(), intended to prevent the program panic? Or is it possible to use a backoff strategy to retry it? backon crate etc.

#[inline]
  unsafe fn dispatch_handler<F>(hwnd: HWND, function: F)
  where
    F: FnMut() + 'static,
  {
    // We double-box because the first box is a fat pointer.
    let boxed = Box::new(function) as Box<dyn FnMut()>;
    let boxed2: Box<Box<dyn FnMut()>> = Box::new(boxed);

    let raw = Box::into_raw(boxed2);

    let res = PostMessageW(hwnd, *EXEC_MSG_ID, WPARAM(raw as _), LPARAM(0));
    assert!(
      res.is_ok(),
      "PostMessage failed ; is the messages queue full?"
    );
  }

And I see this dispatcher should call when current thread is not the main thread. If I create the webview window in app_handle.run_on_main_thread() and it could avoid this issue?

[FabianLars]

And I see this dispatcher should call when current thread is not the main thread. If I create the webview window in app_handle.run_on_main_thread() and it could avoid this issue?

Tauri should take care of the thread requirements internally already.

Maybe we could modify the the assert! to log::error!()

Yeah, that sounds reasonable - @lucasfernog ?

Or is it possible to use a backoff strategy to retry it? backon crate etc.

hmm, idk i personally would prefer to try to prevent these before looking into some retry mechanism but don't have any hard feelings about it.