[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.

[greenhat616]

@FabianLars @lucasfernog Has there been any breakthrough on this issue? We're receiving increasingly frequent feedback from users about it. The problem tends to occur shortly after a webview window is closed. I suspect it might be due to ongoing IPC operations being sent to the window during its closure.

We may have to manually catch this crash using panic::take_hook, and then display an option to ignore the error.

[wonfen]

@FabianLars @lucasfernog @amrbashir Tons of feedback on our project, any ideas how to fix it? https://github.com/clash-verge-rev/clash-verge-rev/issues/1779 https://github.com/clash-verge-rev/clash-verge-rev/issues/1774 https://github.com/clash-verge-rev/clash-verge-rev/issues/1784

any clues from the stack trace? https://github.com/tauri-apps/tauri/issues/11120

[greenhat616]

@wonfen It seem that Tauri do not impl cancelable ipc or send barrier(block ipc while the window is closing), and it just panic while ipc is failed -- That's why the ignore in panic hook is useful.

[wonfen]

@wonfen It seem that Tauri do not impl cancelable ipc or send barrier(block ipc while the window is closing), and it just panic while ipc is failed -- That's why the ignore in panic hook is useful.

But the process is still crashed after ignore the panic? I don't know what else we can do in our end.

[greenhat616]

@wonfen It seem that Tauri do not impl cancelable ipc or send barrier(block ipc while the window is closing), and it just panic while ipc is failed -- That's why the ignore in panic hook is useful.

But the process is still crashed after ignore the panic? I don't know what else we can do in our end.

Are you using the panic = "abort"?

In this way, the program will exit immediately after hook executed, and there is no chance for cleanup logic defined in Drop trait.

You'd better use the panic = "unwind" instead.

Here is a dialogue describing the behavior of panic. https://zhuanlan.zhihu.com/p/687092686

[wonfen]

Are you using the panic = "abort"?

In this way, the program will exit immediately after hook executed, and there is no chance for cleanup logic defined in Drop trait.

You'd better use the panic = "unwind" instead.

Here is a dialogue describing the behavior of panic. https://zhuanlan.zhihu.com/p/687092686

I got what you mean, you’re saying that we can use a panic hook to help identify the cause of a panic, but it doesn’t directly solve the panic itself.

[wonfen]

Hi @FabianLars @lucasfernog is there anything I can do in our end?

[lvfch]

Is there any progress on this issue? I also frequently encounter this problem in my project

[Fly-Potato]

@FabianLars @lucasfernog @amrbashir Can this issue be fixed as soon as possible

[wonfen]

@FabianLars @lucasfernog @amrbashir Is there any additional information or resources we can provide beyond the Stack trace in https://github.com/tauri-apps/tauri/issues/11120 to assist with resolving this bug? Our app serves over 1 million users, so a timely resolution would have a significant positive impact.

[amrbashir]

@wonfen do you have a minimal reproducible example I can test with? or steps to reproduce.

[aramrw]

I just wanted to confirm that I get this same error. So far it doesn't actually seem like it causes any problems but I will trace my code and update if I find out where it happens.

[Fly-Potato]

@amrbashir please look at https://github.com/tauri-apps/tauri/issues/10893

[amrbashir]

@Fly-Potato that's not the same issue and the blocking of open function from shell plugin has been fixed in https://github.com/tauri-apps/plugins-workspace/pull/1881

[Fly-Potato]

@amrbashir Okay, the above problem probably occurs in multi window situations. After the current window processes the data, it sends multiple events to the main window. The main window receives the message and performs further processing. At this time, it will concurrently call the HTTP plugin, causing the main process to freeze

[amrbashir]

I am not sure how the freezing is related to this issue, I am specifically asking for repro about PostMessage failed; is the messages queue full

[oomeow]

@amrbashir I reproduced the issue in my repo tauri-app, this is a simple tauri app example. Execution steps: Click the Greet button -> Close the window immediately then the problem will appear

[lvfch]

Still not solved? I'm ready to give up on using tauri. The community is too inactive and the problem solving is so slow. I'm going to switch to a more stable framework.

[don41382]

any update on this issue?

[ajaykumargdr]

In my case finishing all the operations before closing the window, fixed the PostMessage failed issue.