fix(e2e): reclaim stale :4445 before each Windows webdriver session

Author: shaunwarman

e2e-webview/support/browser.ts

@@ -1,10 +1,16 @@
 import { remote } from 'webdriverio';
 import { execFile } from 'node:child_process';
+import net from 'node:net';
 
 type RemoteOptions = Parameters<typeof remote>[0];
 
 let current: WebdriverIO.Browser | undefined;
 
+// The in-app (tauri-plugin-webdriver) server the app binds once tauri-webdriver
+// spawns it. Only one app instance can hold it at a time, so a stale instance
+// here is what stalls the next spec's newSession.
+const IN_APP_WEBDRIVER_PORT = 4445;
+
 /**
  * Windows-only safety net against native-dialog session poisoning.
  *
@@ -16,9 +22,11 @@ let current: WebdriverIO.Browser | undefined;
  * subsequent spec cascades. Force-killing the app frees the port and tears down
  * the stuck dialog, so each spec gets a clean instance.
  *
- * Runs only in teardown (closeBrowser), so a spec's app is always reclaimed
- * before the next spec launches its own — without adding latency to the tight
- * beforeAll/newBrowser budget. No-op on macOS/Linux: they dismiss the dialog
+ * Runs in teardown (closeBrowser) and, defensively, again right before the next
+ * spec connects (newBrowser) — teardown alone has two holes that still poison
+ * the next launch: taskkill returns before the OS releases :4445, and a spec
+ * whose own beforeAll timed out never set `current`, so its closeBrowser was a
+ * no-op and nothing was reclaimed. No-op on macOS/Linux: they dismiss the dialog
  * reliably, those CI rows don't exhibit the cascade, and a name-based kill
  * there could take out a developer's `tauri dev` instance during a local run.
  */
@@ -35,7 +43,49 @@ async function forceKillApp(): Promise<void> {
   });
 }
 
+/**
+ * Resolves true when nothing is listening on the in-app webdriver port — i.e. a
+ * prior app instance has fully exited and released it. A localhost connect
+ * either completes or refuses promptly; on the unlikely timeout we treat the
+ * port as free (no firewall drops loopback) so the wait can't wedge.
+ */
+function isPortFree(port: number, host = '127.0.0.1', timeoutMs = 500): Promise<boolean> {
+  return new Promise((resolve) => {
+    const socket = net.connect({ port, host });
+    const done = (free: boolean) => {
+      socket.removeAllListeners();
+      socket.destroy();
+      resolve(free);
+    };
+    socket.setTimeout(timeoutMs);
+    socket.once('connect', () => done(false)); // something is still listening
+    socket.once('timeout', () => done(true));
+    socket.once('error', () => done(true)); // ECONNREFUSED → free
+  });
+}
+
+async function waitForPortFree(port: number, capMs = 6000): Promise<void> {
+  const deadline = Date.now() + capMs;
+  while (Date.now() < deadline) {
+    if (await isPortFree(port)) return;
+    await new Promise((r) => setTimeout(r, 250));
+  }
+  // Best-effort: fall through after the cap. remote() then proceeds as it did
+  // before this guard existed — no worse than the prior behaviour.
+}
+
 export async function newBrowser(opts: RemoteOptions): Promise<WebdriverIO.Browser> {
+  // Pre-launch reclaim (Windows only). Before connecting, kill any app instance
+  // a prior spec left behind and wait for :4445 to actually free, so this
+  // session never races a dying instance for the port — the cascade that
+  // otherwise stalls newSession past the 30s beforeAll ceiling and reds the
+  // gate. On the first spec there's nothing to kill and the port is already
+  // free, so this costs ~one refused connect. No-op on macOS/Linux (see
+  // forceKillApp).
+  if (process.platform === 'win32') {
+    await forceKillApp();
+    await waitForPortFree(IN_APP_WEBDRIVER_PORT);
+  }
   current = await remote(opts);
   return current;
 }