[fetch] Partially fix test instability in Safari #16421
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Safari reports inconsistent results for this test. Although the state of the browser's internal cookie store can cause interference when the test is executed repeatedly, Safari demonstrates instability within the results of a single execution which may be unintentional.
wpt-pr-bot
requested review from
annevk,
domfarolino,
jdm,
mnot,
youennf and
yutakahirano
|
Closing, given it no longer appears to be flaky in Safari. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Safari reports inconsistent results for this test, as demonstrated on wpt.fyi:
This is partially due to the browser's more aggressive caching strategy, as can be seen in the "Network" tab of the developer's console:
The caching can be disabled by using a combination of HTTP headers (both
Cache-ControlandVaryappear to be necessary). Unfortunately, it looks like there's further instability that remains even after caching has been disabled. I've included a new test (not really fit formaster) which demonstrates the instability. Here's a screenshot of the kind of results I have in mind:The initial sub-test failure isn't too concerning--some cookies could be lingering from a previous test. I can't explain the second sub-test failure, though. While the absence of the cookie named
ais expected (it is removed by the cleanup logic of the first sub-test), the absence of the cookie namedksurprises me.@burg or @eric-carlson can you verify this?