Skip to content
This repository has been archived by the owner on Nov 6, 2019. It is now read-only.

Intermittent timeouts in Safari #615

Closed
jugglinmike opened this issue Oct 3, 2018 · 5 comments
Closed

Intermittent timeouts in Safari #615

jugglinmike opened this issue Oct 3, 2018 · 5 comments

Comments

@jugglinmike
Copy link
Collaborator

The nascent Mac Mini/Safari setup has demonstrated its first instability 🎉

wptrunner occasionally times out while running WebDriver specification tests in Safari and Safari Technology Preview. (While we've been testing Safari for over a year, we haven't yet experienced this because that testing has occurred on Sauce Labs. The WPT CLI skips "wdspec" tests when running on that service.)

The timeouts occur between tests (not during), and while no single test is responsible, all the timeouts occur immediately following a test concerning user prompts.

I can reproduce this via direct invocations of wpt run in about 10% of trials. This makes it likely to interfere with many collection attempts due to our sub-optimal segmenting strategy (see gh-614). That's mostly a concern for me because it means more manual intervention--I'm hopeful that I can maintain reliable results until we get this fixed. (Though today's collection will be delayed by ~24 hours because I didn't schedule the "rescue" builds in time.)

@jimevans Does this timeout sound familiar to you? It seems distinct from the TAB key timeouts you were describing in IRC the other day.

@jugglinmike
Copy link
Collaborator Author

This problem continues to interfere with results collection from Safari. I'm still researching the root cause.

@gsnedders
Copy link
Member

One question is why are we not recovering from this? Because destroying/creating a new WebDriver session doesn't restart Safari and there's some shared state?

@jgraham
Copy link
Collaborator

jgraham commented Oct 9, 2018

Honestly if it's just a small number of known tests then we probably just want to disable them for now.

The wdspec tests share a session for performance reasons (each new session typically involves restarting the whole browser so is slow). That does mean that you can get cascading failures if the session gets into a state where it can't accept new commands. Typically we'd recover by noticing the unexpected failure and then restarting the runner. But of course since we don't have expectation data we don't do that on wpt.fyi.

@jugglinmike
Copy link
Collaborator Author

This appears to be an issue in wptrunner, though the conditions that cause it only occur when testing Safari (today, at least). More info here: web-platform-tests/wpt#13446 and a proposed fix here: web-platform-tests/wpt#13447

@jugglinmike
Copy link
Collaborator Author

We merged web-platform-tests/wpt#13447 to address this, and the subsequent collections for Safari and Safari Technology Preview both completed successfully.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants