Closed Bug 1916221 Opened 1 year ago Closed 1 year ago

Frequent failure in testing/web-platform/tests/webdriver/tests/bidi/network/continue_response/cookies.py

Categories

(Remote Protocol :: WebDriver BiDi, defect, P2)

defect
Points:
2

Tracking

(firefox-esr115 unaffected, firefox-esr128 unaffected, firefox130 unaffected, firefox131 unaffected, firefox132 fixed)

RESOLVED FIXED
132 Branch
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)

Assignee: nobody → amarchesini
Status: NEW → ASSIGNED
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]
Attachment #9422053 - Attachment description: WIP: Bug 1916221 - Fix Intermittent failure in testing/web-platform/tests/webdriver/tests/bidi/network/continue_response/cookies.py, → Bug 1916221 - Fix Intermittent failure in testing/web-platform/tests/webdriver/tests/bidi/network/continue_response/cookies.py,
Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a35755338025 Fix Intermittent failure in testing/web-platform/tests/webdriver/tests/bidi/network/continue_response/cookies.py, r=webdriver-reviewers,Sasha
Failed to create upstream wpt PR due to merge conflicts. This requires fixup from a wpt sync admin.
Flags: needinfo?(james)
Flags: needinfo?(aborovova)
Whiteboard: [necko-triaged] → [necko-triaged], [wptsync upstream error]
Regressions: 1916251
Duplicate of this bug: 1916238
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 132 Branch

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!

Status: RESOLVED → REOPENED
Flags: needinfo?(amarchesini)
Resolution: FIXED → ---
Target Milestone: 132 Branch → ---
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/47933 for changes under testing/web-platform/tests
Whiteboard: [necko-triaged], [wptsync upstream error][stockwell needswork:owner] → [necko-triaged], [wptsync upstream][stockwell needswork:owner]
Flags: needinfo?(james)
Flags: needinfo?(aborovova)
Upstream PR merged by moz-wptsync-bot
Summary: Intermittent failure in testing/web-platform/tests/webdriver/tests/bidi/network/continue_response/cookies.py → Frequent failure in testing/web-platform/tests/webdriver/tests/bidi/network/continue_response/cookies.py
Status: REOPENED → ASSIGNED
Component: Networking: Cookies → WebDriver BiDi
Product: Core → Remote Protocol

Do we actually know what regressed this test? It's actually a new test that Julian added recently on bug 1853887.

Flags: needinfo?(jdescottes)

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.

Right, I added this test recently, but the failures started after Bug 1913161 landed 3 days ago I believe.

Flags: needinfo?(jdescottes)

The regressed-by info was correctly set on the duplicate bug 1916238, but not here.

Regressed by: 1913161

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?

Regressed by: 1909980
No longer regressed by: 1913161

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.

Blocks: 1917288
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b04eab8729b7 [wdspec] Fix continueResponse cookie test intermittent with flaky expiry date parsing r=baku,webdriver-reviewers,Sasha
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/48019 for changes under testing/web-platform/tests
Assignee: amarchesini → jdescottes
Status: ASSIGNED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 132 Branch
Points: --- → 2
Whiteboard: [necko-triaged], [wptsync upstream][stockwell disable-recommended] → [webdriver:m12][necko-triaged], [wptsync upstream][stockwell disable-recommended]
No longer regressions: 1916251
Upstream PR merged by moz-wptsync-bot
Flags: needinfo?(amarchesini)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: