Frequent failure in testing/web-platform/tests/webdriver/tests/bidi/network/continue_response/cookies.py
Categories
(Remote Protocol :: WebDriver BiDi, defect, P2)
Tracking
(firefox-esr115 unaffected, firefox-esr128 unaffected, firefox130 unaffected, firefox131 unaffected, firefox132 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | unaffected |
| firefox130 | --- | unaffected |
| firefox131 | --- | unaffected |
| firefox132 | --- | fixed |
People
(Reporter: baku, Assigned: jdescottes)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: intermittent-failure, regression, Whiteboard: [webdriver:m12][necko-triaged], [wptsync upstream][stockwell disable-recommended])
Attachments
(2 files)
| Reporter | ||
Comment 1•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 5•1 year ago
|
||
| bugherder | ||
Comment 6•1 year ago
|
||
The problem seems to persist, as it can be seen here. It looks that is quite frequent now.
Hi Andrea! Could you please take another look?
Thank you!
| Comment hidden (Intermittent Failures Robot) |
Updated•1 year ago
|
Updated•1 year ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
Updated•1 year ago
|
Comment 12•1 year ago
|
||
Do we actually know what regressed this test? It's actually a new test that Julian added recently on bug 1853887.
Comment 13•1 year ago
|
||
It's related to the expire date: expected = 1725633380, actual = 1725633379 which corresponds to Friday, 6. September 2024 14:36:20 and Friday, 6. September 2024 14:36:19.
Might there be a rounding error somewhere given that the actual timestamp differs by just 1 from the expected one.
| Assignee | ||
Comment 14•1 year ago
|
||
Right, I added this test recently, but the failures started after Bug 1913161 landed 3 days ago I believe.
| Assignee | ||
Comment 15•1 year ago
|
||
The regressed-by info was correctly set on the duplicate bug 1916238, but not here.
Comment 16•1 year ago
|
||
Set release status flags based on info from the regressing bug 1913161
| Assignee | ||
Comment 17•1 year ago
|
||
Oh I think the regression info is wrong actually. This is most likely regressed by Bug 1909980.
So I initially suspected a rounding issue with datetime apis, since timestamps are in microseconds, int() would round the value while strftime would truncate the extra data.
But even when hardcoding the values (timestamp and formatted string), the intermittent would persist. Sometimes the computed expiry timestamp is still off by 1.
Looking at the patch from Bug 1909980, it makes more sense. We add a delta to the provided expiry at https://searchfox.org/mozilla-central/rev/f09e3f9603a08b5b51bf504846091579bc2ff531/netwerk/cookie/CookieParser.cpp#753-755
if (StaticPrefs::network_cookie_useServerTime()) {
expires += delta;
} else if (expires <= aCurrentTime &&
And turning off the preference network.cookie.useServerTime "fixes" the intermittent.
So either we do that, or we only assert that actual and expected expiry are close enough. But I imagine there's no guarantee that the gap will always be at most 1ms?
| Assignee | ||
Comment 18•1 year ago
|
||
The parsed expiry for cookies might be slightly different from the provided value, because
Firefox will attempt to compensate the delta between the server time and the current time.
Instead of expecting an exact match, assert that the actual expiry is within 1ms of the expected
value.
| Comment hidden (Intermittent Failures Robot) |
Comment 20•1 year ago
|
||
Updated•1 year ago
|
| Comment hidden (Intermittent Failures Robot) |
Comment 23•1 year ago
|
||
| bugherder | ||
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Updated•1 year ago
|
| Reporter | ||
Updated•1 year ago
|
Description
•