Closed Bug 1637844 Opened 5 years ago Closed 5 years ago

Perma TEST-UNEXPECTED-PASS | /webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html | [video] getSynchronizationSources() should not contain captureTimestamp if absolute capture time RTP header extension is not offered - expected TIMEOUT

Categories

(Core :: WebRTC, defect, P5)

defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: aryx)

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed:other])

Attachments

(1 obsolete file)

Filed by: nbeleuzu [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=302205544&repo=mozilla-central
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/YX-HWkokRM-1f7IFqpnc-w/runs/0/artifacts/public/logs/live_backing.log


[task 2020-05-14T03:41:55.762Z] 03:41:55 INFO - TEST-PASS | /webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html | [audio] getSynchronizationSources() should not contain captureTimestamp if absolute capture time RTP header extension is offered, but not answered
[task 2020-05-14T03:41:55.763Z] 03:41:55 INFO - TEST-FAIL | /webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html | [audio] getSynchronizationSources() should contain captureTimestamp if absolute capture time RTP header extension is negotiated - assert_false: Absolute capture time RTP header extension is not answered expected false got true
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - checkAbsCaptureTimeAndExchangeAnswer@http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:91:17
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - asyncinitiateSingleTrackCall@http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:144:9
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - async
@http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:196:36
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1988:25
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - promise_test/tests.promise_tests</<@http://web-platform.test:8000/resources/testharness.js:592:36
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - promise_test/tests.promise_tests<@http://web-platform.test:8000/resources/testharness.js:591:20
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - promise callbackpromise_test@http://web-platform.test:8000/resources/testharness.js:590:51
[task 2020-05-14T03:41:55.764Z] 03:41:55 INFO - @http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:195:15
[task 2020-05-14T03:41:55.765Z] 03:41:55 INFO - TEST-UNEXPECTED-PASS | /webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html | [video] getSynchronizationSources() should not contain captureTimestamp if absolute capture time RTP header extension is not offered - expected TIMEOUT
[task 2020-05-14T03:41:55.765Z] 03:41:55 INFO - TEST-INFO | expected TIMEOUT
[task 2020-05-14T03:41:55.765Z] 03:41:55 INFO -
[task 2020-05-14T03:41:55.765Z] 03:41:55 INFO - TEST-UNEXPECTED-PASS | /webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html | [video] getSynchronizationSources() should not contain captureTimestamp if absolute capture time RTP header extension is offered, but not answered - expected NOTRUN
[task 2020-05-14T03:41:55.765Z] 03:41:55 INFO - TEST-INFO | expected NOTRUN
[task 2020-05-14T03:41:55.766Z] 03:41:55 INFO -
[task 2020-05-14T03:41:55.766Z] 03:41:55 INFO - TEST-UNEXPECTED-FAIL | /webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html | [video] getSynchronizationSources() should contain captureTimestamp if absolute capture time RTP header extension is negotiated - assert_false: Absolute capture time RTP header extension is not answered expected false got true
[task 2020-05-14T03:41:55.766Z] 03:41:55 INFO - checkAbsCaptureTimeAndExchangeAnswer@http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:91:17
[task 2020-05-14T03:41:55.766Z] 03:41:55 INFO - async
initiateSingleTrackCall@http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:144:9
[task 2020-05-14T03:41:55.767Z] 03:41:55 INFO - async*@http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:196:36
[task 2020-05-14T03:41:55.767Z] 03:41:55 INFO - Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1988:25
[task 2020-05-14T03:41:55.767Z] 03:41:55 INFO - promise_test/tests.promise_tests</<@http://web-platform.test:8000/resources/testharness.js:592:36
[task 2020-05-14T03:41:55.767Z] 03:41:55 INFO - promise_test/tests.promise_tests<@http://web-platform.test:8000/resources/testharness.js:591:20
[task 2020-05-14T03:41:55.767Z] 03:41:55 INFO - promise callback*promise_test@http://web-platform.test:8000/resources/testharness.js:590:51
[task 2020-05-14T03:41:55.768Z] 03:41:55 INFO - @http://web-platform.test:8000/webrtc-extensions/RTCRtpSynchronizationSource-captureTimestamp.html:195:15
[task 2020-05-14T03:41:55.768Z] 03:41:55 INFO - TEST-INFO | expected NOTRUN

The skipping is in the harness itself, so it shouldn't be related to the test scheduling change.

Maybe related to the recent work on moving some WPT tests to backlog?

Flags: needinfo?(mcastelluccio) → needinfo?(james)

(Also, if it's passing, maybe some new WebRTC extension was implemented, and: we should mark it as pass)

Flags: needinfo?(dminor)

Hey Nico, do you mind having a look at this one? Thanks!

Flags: needinfo?(dminor) → needinfo?(na-g)

Agree with Marco, I don't think this could be caused by scheduling changes.

Flags: needinfo?(ahal)

I haven't moved any of tests from that directory to backlog. Most likely the test is working now and we didn't see it on autoland due to skipping expected timeouts on autoland.

Flags: needinfo?(jmaher)

Nothing has changed with regard to captureTime (an extension field we never emit), though I did land a patch yesterday effecting getSynchronizationSources.

This is probably legitimately passing we don't support the absolute capture time RTP extension, and thus we never report captureTime. I think the right course of action given that is to mark it as PASS, so that when / if we support absolute capture time it has the opportunity to fail.

Is it normal for NOTRUN tests to be run under some circumstances like above?

Yes, marking it as expected pass seems like the right thing to do.

A test being marked NOTRUN means that a test declared a subtest, but then no steps of the test were run. That typically happens either if we timeout before getting to the subtest (which can be intermittent) or if there's an uncaught exception before we get to the subtest.

Flags: needinfo?(james)
Assignee: nobody → aryx.bugmail
Status: NEW → ASSIGNED
Attachment #9149341 - Attachment description: Bug 1637844 - Update video steps in RTCRtpSynchronizationSource-captureTimestamp.html to pass. r=jgraham → Bug 1637844 - Update video steps in RTCRtpSynchronizationSource-captureTimestamp.html to pass. r=jgraham DONTBUILD
Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/autoland/rev/505be09fd733 Update video steps in RTCRtpSynchronizationSource-captureTimestamp.html to pass. r=jmaher DONTBUILD
Keywords: leave-open
Whiteboard: [stockwell disable-recommended]
Keywords: leave-open
Whiteboard: [stockwell disable-recommended]

Failures here are fixed by bug 1637486.

Whiteboard: [stockwell disable-recommended] → [stockwell fixed:other]
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(na-g)
Flags: needinfo?(aryx.bugmail)
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Attachment #9149341 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: