Intermittent service-workers/service-worker/fetch-header-visibility.https.html | Visibility of defaulted headers during interception - Test timed out

REOPENED
Unassigned

Status

()

defect
P5
normal
REOPENED
3 years ago
2 years ago

People

(Reporter: RyanVM, Unassigned)

Tracking

({intermittent-failure})

Trunk
mozilla52
Points:
---

Firefox Tracking Flags

(firefox48 affected)

Details

Attachments

(1 attachment)

Flags: needinfo?(bkelly)
Let's see if this reproduces much before spending a lot of time here.  Nothing immediately jumps out at me.
Flags: needinfo?(bkelly)

Comment 2

3 years ago
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Comment on attachment 8809581 [details] [diff] [review]
Don't respondWith twice in fetch-rewrite-worker.js

Review of attachment 8809581 [details] [diff] [review]:
-----------------------------------------------------------------

How is this an intermittent and not always a failure?
Attachment #8809581 - Flags: review?(bkelly) → review+

Comment 5

3 years ago
Pushed by catalin.badea392@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/85bef7bdcafc
Don't respondWith twice in fetch-rewrite-worker.js r=bkelly

Comment 6

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/85bef7bdcafc
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
(In reply to Ben Kelly [:bkelly] from comment #4)
> Comment on attachment 8809581 [details] [diff] [review]
> Don't respondWith twice in fetch-rewrite-worker.js
> 
> Review of attachment 8809581 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> How is this an intermittent and not always a failure?

This was not the issue. I assumed this was causing the intermittent failure because I only recently started
to see a failure of this test in my try runs for bug 1263304. According to the spec, the fetch event should
still successfully respond even if there's a second respondWith call that throws. My patches were breaking this, causing the failure I was seeing.

The patch itself is not a bad change, but it didn't fix whatever is causing the intermittent failure.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.