https://searchfox.org/mozilla-central/source/testing/web-platform/meta/url/historical.any.js.ini

if (processor == "x86") and fission and not debug: ["OK", "ERROR"]

The DOM Fission team is relying on feature teams to debug and fix Fission failures in their tests. If the failure looks like a bug in Fission's DOM or IPC changes, you can send the bug back to me.

We're hoping to enable Fission for a subset of Nightly users in early Q3, so we would like WPT tests to be green for Fission by end of Q2. Whether a particular test failure actually blocks shipping Fission is up to the discretion of the feature team. You all would know better than the DOM Fission which test failures are most important.

You can enable Fission when running WPT tests locally using mach wpt --enable-fission.

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

From what I can tell, we don't even run web-platform-tests on 32 bit x86 with fission enabled. if (processor == "x86") and fission and not debug: ["OK", "ERROR"] came along with the initial wpt sync bot push and I can't see what it ran on try since it has all expired.

Looking at an active data query on https://activedata.allizom.org/tools/query.html:

{
	"from":"unittest",
	"groupby":["run.key","result.status"],
	"limit":1000,
	"where":[
		{"eq":{"repo.branch.name":["autoland","mozilla-central"]}},
		{"eq":{"run.suite.name":"web-platform-tests"}},
		{"eq":{"result.test":"/url/historical.any.worker.html"}},
		{"gte":{"result.start_time":{"date":"today-week"}}}
	]
}

We have:

"run.key"	"result.status"	"count"
"test-linux1804-64/debug-web-platform-tests-e10s-5"	"OK"	756
"test-windows7-32/debug-web-platform-tests-e10s-5"	"OK"	751
"test-macosx1014-64-shippable/opt-web-platform-tests-e10s-11"	"OK"	739
"test-windows10-64/debug-web-platform-tests-e10s-5"	"OK"	154
"test-android-em-7.0-x86_64/debug-geckoview-web-platform-tests-e10s-5"	"OK"	145
"test-windows7-32-shippable/opt-web-platform-tests-e10s-11"	"OK"	145
"test-android-em-7.0-x86_64/opt-geckoview-web-platform-tests-e10s-5"	"OK"	144
"test-linux1804-64-asan/opt-web-platform-tests-e10s-19"	"OK"	144
"test-macosx1014-64/debug-web-platform-tests-e10s-19"	"OK"	144
"test-linux1804-64-shippable/opt-web-platform-tests-e10s-11"	"OK"	142
"test-linux1804-64-qr/debug-web-platform-tests-fis-e10s-5"	"OK"	141
"test-windows10-64-shippable/opt-web-platform-tests-e10s-11"	"OK"	141
"test-windows10-64-qr/opt-web-platform-tests-e10s-11"	"OK"	30
"test-linux1804-64-qr/debug-web-platform-tests-e10s-5"	"OK"	28
"test-windows10-64-ccov/opt-web-platform-tests-e10s-5"	"OK"	28
"test-linux1804-32-shippable/opt-web-platform-tests-e10s-11"	"OK"	26
"test-linux1804-64-ccov/opt-web-platform-tests-e10s-11"	"OK"	26
"test-linux1804-64-shippable-qr/opt-web-platform-tests-e10s-11"	"OK"	26
"test-linux1804-64-qr/opt-web-platform-tests-e10s-11"	"OK"	25
"test-linux1804-64-qr/opt-web-platform-tests-fis-e10s-11"	"OK"	25
"test-linux1804-64/opt-web-platform-tests-e10s-11"	"OK"	25
"test-windows10-64-qr/debug-web-platform-tests-e10s-5"	"OK"	25
"test-windows10-64/opt-web-platform-tests-e10s-11"	"OK"	25
"test-windows7-32/opt-web-platform-tests-e10s-11"	"OK"	25
"test-windows10-64-qr/opt-web-platform-tests-fis-e10s-11"	"OK"	24
"test-windows10-64-shippable-qr/opt-web-platform-tests-e10s-11"	"OK"	24
"test-windows10-64/debug-web-platform-tests-e10s-5"	"CRASH"	1

Which indicates this test is running well, and again, doesn't appear to even run on 32 bit non debug builds. Also confirmed by https://searchfox.org/mozilla-central/rev/3446310d6cc5c85cde16a82eccf560e9b71a3d44/taskcluster/ci/test/web-platform.yml#17

Am I misunderstanding processor == x86? I'm assuming that will be false running on x86_64, no? :jgraham, am I assuming correctly here? Did we run fission 32 bit in the past? Does the wpt sync bot run extra jobs or something?

I'm tempted to just remove the ERROR secondary expected result, and call this WORKSFORME. :jgraham, does that seem like a reasonable solution to you?

Yes, I think that's reasonable. I wonder if there's a bug in the manifest update somewhere; I'd expect us to remove metadata for configurations that don't exist (but perhaps we only do that if there are other changes or something).

Note that the right fix in that case is just to delete the file.

We don't appear to run fission on any platform where
processor == "x86", and querying activedata for results of
url/historical.any.worker.html shows no "ERROR"s. Also, the
taskcluster artifacts for the original sync that recorded the
intermittent error have expired and I'm unable to reproduce it
myself. With all that in mind I think it makes sense to just
remove the intermittent "ERROR" as an expected result.

https://hg.mozilla.org/mozilla-central/rev/0d6adfdd3b38