Browser drag timeout crashes the server and cancels unrelated threads #17322

Activity

1. juliusmarminge commented on Oct 8, 2026

   

   juliusmarminge

   on Oct 8, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the write-up. I read this against main at 9b0df1358. I did not reproduce the drag timeout.

   The drag promise can reject before anything observes it

   drag starts source.dragTo(...) and only awaits that promise after the target bounding box and a pointer update (ServerBrowserPage.ts:374-388):

   const dropped = source.dragTo(target, { timeout });
   const end = await target.boundingBox({ timeout }).catch(() => null);
   if (end) await pointer({ x: end.x + end.width / 2, y: end.y + end.height / 2 }, "move");
   await dropped;

   dragTo and boundingBox run together. If the drag times out while boundingBox or the pointer update is still pending, that rejection has no handler yet. Node treats a rejection as unhandled when nothing is attached by the end of that turn, so a later await dropped does not take it back. The same function on the crashing build (5e2225671f) has this shape, and it is unchanged on current main.

   I did not find another Playwright call in this file that is started and then left alone across an await. click also starts its click before doing other work, but Promise.race attaches to that promise in the same turn (ServerBrowserPage.ts:243-253). The caller of drag does await it (ServerBrowser.ts:1675-1678), which does not cover the gap inside drag.

   How that becomes a process exit

   There is no general handler that keeps the server up. Loading the server imports the Cursor driver, which imports cursorSdk.ts, and that module installs an unhandledRejection listener as a side effect (server.ts:57 → ProviderInstanceRegistryHydration.ts:37 → builtInDrivers.ts:27 → CursorDriver.ts:47 → CursorAuth.ts:19 → cursorSdk.ts:50-65). That listener ignores one Cursor shell-spawn failure. For every other rejection, when it is the only listener, it prints the reason and calls process.exit(1). A Codex session still loads this module, because the import is on the server boot path rather than on the Codex driver. The engines field asks for Node 22 or newer (package.json), where an unhandled rejection also exits if no listener is installed. Either way the child exits 1.

   The launcher then throws Active child exited unexpectedly (1) (serviceLauncher.ts:602) and the CLI prints that as [service-launcher] ... before setting exit code 1 (cli/serviceLauncher.ts:20-24). The name: 'TimeoutError' line in the report looks like console.error of the Playwright error, which is what this listener does. I have not seen the journal itself.

   The four cancelled threads look like startup recovery

   After the process comes back, startup runs provider-runtime recovery and logs V2 orchestration recovery completed (serverRuntimeStartup.ts:518-539). Recovery collects runs in preparing, starting, running, or waiting and writes each as cancelled (ProviderRuntimeRecoveryService.ts:71-80, :319-327). Sessions that are not already stopped or in error are set to stopped. The events I read update that runtime state. They do not delete thread messages. terminalizedRuns: 4 in the report matches that count, so the four cancellations look like a consequence of the exit, not a second bug in the drag tool.

   Related, not duplicates

   • #16794 is the same class of failure (one unhandled rejection exits the process and recovery stops other sessions) with a different exception, a provider pipe ECONNRESET.
   • #14115 is two servers on one database. That does not explain the drag exception.
   • #16921 is a browser timeout that evicts the shared browser host. It does not go through this un-awaited dragTo.

   No open PR changes this gap. #16941, #16728, and #16963 edit ServerBrowserPage.ts, and each of those heads still starts dragTo and then awaits the bounding box before awaiting the drag.

   Smallest fix

   Observe the drag promise in the same turn it is created, then rethrow after the pointer update. For example, attach .catch immediately, keep the pointer update, and throw the stored error afterwards. A new process-wide unhandledRejection listener is a worse place to fix this: the Cursor guard skips its process.exit(1) when another listener is already registered (cursorSdk.ts:56-58), so an extra listener can change exit behavior for unrelated rejections.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 8, 2026
3. Yash-Singh1

   closed this as completedin #17360on Oct 9, 2026