PoisonError after first few sequential tests; tauri-wd self-terminates on macOS (v0.1.3)

[shyhunter]

Summary

After 1–3 successful sequential WebDriver tests, tauri-wd starts emitting lock poisoned: PoisonError { .. } repeatedly, then self-terminates with exit code 0. All subsequent script/execute requests from the WebDriver client fail with plugin request failed: error sending request for url.

Environment

• tauri-plugin-webdriver-automation 0.1.3 (latest)
• tauri-wd 0.1.3
• Tauri 2.x (tauri = "2", tauri-build = "2")
• macOS 26.5 (Darwin 25.5)
• @wdio/cli ^9.24.0 (mocha framework, maxInstances: 1)
• Plugin gated behind a Cargo feature, included via tauri build --debug --features e2e

Repro shape

A WebDriverIO+Mocha suite of ~15 sequential it(...) cases with this per-test pattern:

afterEach(async () => {
  // ... screenshot on failure ...
  // navigate back to a known state, sometimes via browser.refresh()
});

it("...", async () => {
  await waitForTestId(browser, "open-file-btn");
  await browser.execute((path) => { window.__E2E_OPEN_FILE__ = path; }, fixturePath);
  await clickTestId(browser, "open-file-btn");
  await waitForStep(browser, 1);   // waits for state advance
  // ... rest of flow
});

The first 3 tests pass cleanly (~7s each). At the start of the 4th test (or sometimes during afterEach.browser.refresh() of the 3rd), the plugin enters the poisoned state.

Observed log

[0-0] lock poisoned: PoisonError { .. }
[0-0] WARN webdriver: WebDriverError: plugin request failed: error sending request
      for url (http://127.0.0.1:50058/script/execute) when running "execute/sync" with method "POST"
[0-0] lock poisoned: PoisonError { .. }
[0-0] WARN webdriver: WebDriverError: plugin request failed ...
... (repeats ~40 times) ...
[0-0] tauri-wd exited unexpectedly with code: 0

50058 is an ephemeral port the plugin opens on the Tauri side (separate from tauri-wd's 4444).

Diagnosis hypothesis

PoisonError is std::sync::PoisonError — a Mutex was held by a thread that panicked. A subsequent lock() on the same Mutex returns Err(PoisonError(_)). The plugin appears to log the error string but not recover (.into_inner() would let it continue with possibly-corrupt state).

The repeated "lock poisoned" events suggest each subsequent script-execute call hits the same poisoned Mutex. After ~40 attempts the WD client gives up and tauri-wd shuts down.

This means there's an underlying panic in some earlier branch (within the plugin's request handling, the script-execute path, or the page-refresh handling) that nobody is catching. That panic is what initially poisons the Mutex; everything afterwards is collateral.

Suggestion

• Add unwrap_or_else(|e| e.into_inner()) recovery on the relevant Mutex::lock() call site so a single panic doesn't kill the entire session.
• More importantly, surface the original panic. Right now the panic message is swallowed and only the resulting PoisonError shows up — which makes diagnosis from outside the plugin impossible. A std::panic::set_hook in the plugin's init that logs to the same channel would help users like me file actionable bug reports.

Real-world impact

This blocks a Tauri app's full E2E suite on macOS — the first few tests run, then everything that follows in the same wdio session fails. Reported in the context of shyhunter/Papercut#29.

Happy to test patches against my repro.