Open Bug 1844623 Opened 1 year ago Updated 3 months ago

Intermittent /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | single tracking bug

Categories

(Core :: WebRTC: Networking, defect, P5)

defect

Tracking

()

Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 --- unaffected
firefox115 --- unaffected
firefox116 --- unaffected
firefox117 --- affected
firefox118 --- affected

People

(Reporter: intermittent-bug-filer, Unassigned)

References

(Depends on 1 open bug, Regression)

Details

(4 keywords)

Filed by: imoraru [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=423300706&repo=autoland
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/evacnniRRPOUj_1QUY-Psg/runs/0/artifacts/public/logs/live_backing.log
Reftest URL: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/evacnniRRPOUj_1QUY-Psg/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1


[task 2023-07-20T15:10:18.984Z] 15:10:18     INFO - TEST-PASS | /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | generateKeyFrame timestamp should advance 
[task 2023-07-20T15:10:18.984Z] 15:10:18     INFO - TEST-UNEXPECTED-FAIL | /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | await generateKeyFrame, await generateKeyFrame should see an increase in count of keyframes - assert_equals: expected (string) "got frame" but got (object) object "[object Object]"
[task 2023-07-20T15:10:18.984Z] 15:10:18     INFO - @https://web-platform.test:8443/webrtc-encoded-transform/script-transform-generateKeyFrame.https.html:149:16
[task 2023-07-20T15:10:18.985Z] 15:10:18     INFO - 
[task 2023-07-20T15:10:18.985Z] 15:10:18     INFO - TEST-UNEXPECTED-FAIL | /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | generateKeyFrame rejects when the sender is negotiated inactive, and resumes succeeding when negotiated back to active - assert_equals: expected (string) "got frame" but got (object) object "[object Object]"
[task 2023-07-20T15:10:18.985Z] 15:10:18     INFO - @https://web-platform.test:8443/webrtc-encoded-transform/script-transform-generateKeyFrame.https.html:163:16
[task 2023-07-20T15:10:18.985Z] 15:10:18     INFO - 
[task 2023-07-20T15:10:18.985Z] 15:10:18     INFO - TEST-UNEXPECTED-FAIL | /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | generateKeyFrame rejects when the sender is stopped, even without negotiation - assert_equals: expected (string) "got frame" but got (object) object "[object Object]"
[task 2023-07-20T15:10:18.985Z] 15:10:18     INFO - @https://web-platform.test:8443/webrtc-encoded-transform/script-transform-generateKeyFrame.https.html:191:16
[task 2023-07-20T15:10:18.986Z] 15:10:18     INFO - .
[task 2023-07-20T15:10:18.986Z] 15:10:18     INFO - TEST-OK | /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | took 61725ms

:bwc, since you are the author of the regressor, bug 1631263, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(docfaraday)

I'll keep an eye on this.

Summary: Intermittent TVw /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | single tracking bug → Intermittent /webrtc-encoded-transform/script-transform-generateKeyFrame.https.html | single tracking bug

For some reason win11 is just really slow on this test. I wonder if that's because the tester is just slow, or because there's some win11 flaw in libwebrtc wrt keyframe generation?

Hmm, looking at the logging, it appears that some of these tests are finishing way earlier than intended, before ICE even finishes:

https://treeherder.mozilla.org/logviewer?job_id=423761069&repo=autoland&lineNumber=17199-17201

Maybe having these previous tests still effectively running is bogging down later tests?

See Also: → 1845567

I think I've found a way to make these tests run more smoothly. We were missing a pc.close() on test teardown in some of these test cases, which is not strictly necessary from a spec perspective, but helps things wrap up quicker.

Assignee: nobody → docfaraday
Flags: needinfo?(docfaraday)

Set release status flags based on info from the regressing bug 1631263

Depends on: 1847093

This is low frequency, and indicative of a real problem (bug 1847093), so for now let's leave this be. If bug 1847093 gets a lot worse, we want to notice.

Assignee: docfaraday → nobody
You need to log in before you can comment on or make changes to this bug.