1988681 - [wdspec] avoid race conditions with requests blocked in responseStarted phase

Status: RESOLVED FIXED

(Remote Protocol :: WebDriver BiDi, task, P3)

Description

[Julian Descottes [:jdescottes]]

This bug relates to Bug 1966494 where we described how a request suspended in the responseStarted phase can still populate the cache and then be used for a second request.

The typical scenario where this is problematic in webdriver is:

• add an intercept for responseStarted
• send request to someurl
• (request is blocked, as expected)
• remove the intercept
• send another request to someurl

Here we expect the request to go through, but sometimes it will be blocked as well because we end up reusing the the cached (suspended) response from the first request. We thought this was only the case when race-cache-with-network was disabled, but it seems that on Android 14, this happens intermittently in any case.

The long term solution here is described by bug 1966494, consists in adding a new API to remove entries from the cache, which we would call when a request has no intercept anymore. For now we should at least fix the intermittent.

One option we discussed is to use unique URLs per test to avoid situations where test1 blocks a request and test2 emits a new request which gets suspended. One of the test actually exercises something close to the STRs above, so here we will need to switch to a non-string pattern and generate distinct URLs.

Here is a list of impacted tests:

• add_intercept.py: test_two_intercepts fails because of blocked request in test_other_url
• contexts.py: test_other_context fails because of blocked request in test_frame_context (but it probably can fail on its own even with unique URLs)
• phases.py: test_not_listening_to_phase_event fails because of blocked request in test_request_response_phases

Comment 1

[Julian Descottes [:jdescottes]]

Attachment: Bug 1988681 - [wdspec] avoid race conditions with requests blocked in responseStarted phase

Comment 2

[Julian Descottes [:jdescottes]]

FWIW, Valentin confirmed that we could hit the cache due if Android 14 has faster I/O in Bug 1838145, so the analysis is probably correct and we should move on with the proposed patch here.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/87be5d0c187e
https://hg.mozilla.org/integration/autoland/rev/684c63950d7b
[wdspec] avoid race conditions with requests blocked in responseStarted phase r=webdriver-reviewers,whimboo

Comment 4

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/54901 for changes under testing/web-platform/tests

Comment 5

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/684c63950d7b

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot