1955951 - Running raptor tests leaves the build unable to run wpt tests afterwards.

Status: NEW

(Testing :: Raptor, defect, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

STR (on a clobber build and python 3.10 virtualenv):

$ ./mach build # Doesn't matter debug/opt/artifact/full
$ ./mach raptor -t nytimes --post-startup-delay 0 --verbose # let the test run, or stop once it starts running, also doesn't matter
$ ps -ax # Make sure there are no leftover processess running
$ ./mach wpt testing/web-platform/tests/css/css-viewport/zoom/scrollbar-crash.html # or any test really
...
ERROR /css/css-viewport/zoom/scrollbar-crash.html - Reached error page: about:neterror?e=proxyConnectFailure&u=http%3A//web-platform.test%3A8000/css/css-viewport/zoom/scrollbar-crash.html&c=UTF-8&d=Firefox%20is%20configured%20to%20use%20a%20proxy%20server%20that%20is%20refusing%20connections.
Traceback (most recent call last):
  File "/home/emilio/src/moz/gecko/testing/web-platform/tests/tools/wptrunner/wptrunner/executors/executormarionette.py", line 866, in run_func
    self.result = True, self.func(self.protocol, self.url, self.timeout)
  File "/home/emilio/src/moz/gecko/testing/web-platform/tests/tools/wptrunner/wptrunner/executors/executormarionette.py", line 1275, in do_crashtest
    protocol.base.load(url)
  File "/home/emilio/src/moz/gecko/testing/web-platform/tests/tools/wptrunner/wptrunner/executors/executormarionette.py", line 121, in load
    self.marionette.navigate(url)
  File "/home/emilio/src/moz/gecko/testing/marionette/client/marionette_driver/marionette.py", line 1709, in navigate
    self._send_message("WebDriver:Navigate", {"url": url})
  File "/home/emilio/src/moz/gecko/testing/marionette/client/marionette_driver/decorators.py", line 24, in _
    return func(*args, **kwargs)
  File "/home/emilio/src/moz/gecko/testing/marionette/client/marionette_driver/marionette.py", line 776, in _send_message
    self._handle_error(err)
  File "/home/emilio/src/moz/gecko/testing/marionette/client/marionette_driver/marionette.py", line 788, in _handle_error
    raise errors.lookup(error)(message, stacktrace=stacktrace)
marionette_driver.errors.UnknownException: Reached error page: about:neterror?e=proxyConnectFailure&u=http%3A//web-platform.test%3A8000/css/css-viewport/zoom/scrollbar-crash.html&c=UTF-8&d=Firefox%20is%20configured%20to%20use%20a%20proxy%20server%20that%20is%20refusing%20connections.
stacktrace:
        RemoteError@chrome://remote/content/shared/RemoteError.sys.mjs:8:8
        WebDriverError@chrome://remote/content/shared/webdriver/Errors.sys.mjs:199:5
        UnknownError@chrome://remote/content/shared/webdriver/Errors.sys.mjs:910:5
        checkReadyState@chrome://remote/content/marionette/navigate.sys.mjs:58:24
        onNavigation@chrome://remote/content/marionette/navigate.sys.mjs:347:39
        emit@resource://gre/modules/EventEmitter.sys.mjs:148:20
        receiveMessage@chrome://remote/content/marionette/actors/MarionetteEventsParent.sys.mjs:33:25

I don't know how to recover the ability of running wpts unless I clobber and remove my whole objdir.

Comment 1

[Greg Mierzwinski [:sparky]]

:jgraham, do you know what might be triggering this issue in wpt?

Comment 2

[James Graham [:jgraham]]

Not really, without investigation. We seem to be ending up getting a network error when trying to load a URL. Given we're using a fresh browser profile it shouldn't be anything in the profile. If raptor was leaving some server running it wouldn't obviously make sense that a clobber would fix it, and in any case we'd expect a different error (server being unable to start).

Without investigating more it seems like it's more likely to be something that raptor is doing that affects the objdir, rather than something wrong on the wpt side, but of course that might not be the case.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Yeah, maybe raptor is not clearing the mitmproxy settings or so?

Comment 4

[Greg Mierzwinski [:sparky]]

Thanks for the info :jgraham. I tested out locally with the commands you provided :emilio, and I'm unable to reproduce this issue on python 3.8 and on python 3.10 using recorded websites while having the test run fully. However, if I ctrl+c from the test with a mitmdump process leftover in the background, then I can trigger the failure. So the failure has something to do with the leftover mitmdump process.

After I kill the mitmdump process though, the failure is still being hit. But I could only trigger this failure when I had a mitmdump process leftover to begin with so it's likely, as :jgraham mentioned, that it's doing something with the obj dir.

When I re-run raptor fully without letting a mitmdump process to be leftover, then the failure in wpt goes away without a clobber. I imagine it's something to do with the clean-up we're doing.

Comment 5

[Greg Mierzwinski [:sparky]]

Hmm, maybe it's related to something else. I tried to reproduce the failure again by having multiple mitmdump processes left over, but I'm unable to now. I wonder if there's a port conflict that happens intermittently.

Comment 6

[Kash Shampur [:kshampur] ⌚EST]

in case it is potentially related to the mitmdump stuff, adding bug 1894253 as a related one

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:fbilt, could you have a look please?

For more information, please visit BugBot documentation.