timescale.info#206 · Desktop WebDriver requests have a time limit, so a stalled driver fails the run (#205)
- timeline-app
- pull request
- packages
Closes #205. On PR #203, the desktop bulk edits step hung for an hour. Its waits had time limits, but each WebDriver request inside them (`fetch` in `bench/ui/webdriver.mjs`) had none, so one request the driver never answered held the step until the job limit. ## Changes - **`bench/ui/webdriver.mjs`:** each request fails after `timeout` (60 s by default, an option of `webdriverSession`) with `WebDriver POST /session/…/execute/sync: no answer in 60 s`, followed by tauri-driver's recent output when the caller passes `logs`. Creating the session, which starts the app, may take twice as long. `close()` waits 10 s at most, since runs end with it whether or not the driver stalled. `eval(expression, limit)` can set a shorter limit for one call. - **`test/desktop-bulk.mjs`** and **`bench/ui.mjs`** pass tauri-driver's log. Their page-state dumps on failure wait 10 s at most, so the original error still comes through. - **CI:** `timeout-minutes` on **Desktop bulk edits** (5; usually under a minute) and **UI interactions within budget** (15; usually about 3) as a backstop. ## Checked locally - Against a fake driver that never answers: requests fail at their limit, naming the request and ending with the log. A refused connection still reports as before. - With the real app, freezing WebKitWebDriver (`SIGSTOP`) 15 s into `test/desktop-bulk.mjs` made it fail about 80 s later: 60 s for the stalled request, then 10 s each for the state dump and close. Before the close limit it took about 130 s. - `test/desktop-bulk.mjs` passes normally (36 s). - The desktop UI gate has the same result with and without this change. On this VM, its WebKitWebDriver rejects key and pointer actions on main too, so CI is the real check for the gate.