web-locks/signal.tentative.https.any.serviceworker.html is flaky

[foolip]

#14420 revealed that web-locks/signal.tentative.https.any.serviceworker.html is flaky. This can be seen by running ./wpt run --verify --channel dev --binary which google-chrome-unstable --log-tbpl - chrome /web-locks/signal.tentative.https.any.serviceworker.html locally, producing this table:

Subtest	Results	Messages
	OK
The signal option must be an AbortSignal	PASS
Passing an already aborted signal aborts	PASS
An aborted request results in AbortError	FAIL: 5/10, PASS: 5/10	assert_equals: expected 1 but got 2
Abort after a timeout	FAIL: 4/10, PASS: 6/10	assert_equals: expected 1 but got 2
Signal that is not aborted	PASS
Synchronously signaled abort	PASS
Abort signaled after lock granted	PASS
Abort signaled after lock released	PASS

These are the flaky subtests:

wpt/web-locks/signal.tentative.https.any.js

Lines 38 to 63 in 7d538d1

	promise_test(async t => {
	const res = uniqueName(t);
	// Grab a lock and hold it forever.
	const never_settled = new Promise(resolve => { /* never */ });
	navigator.locks.request(res, lock => never_settled);
	const controller = new AbortController();
	const promise =
	navigator.locks.request(res, {signal: controller.signal},
	t.unreached_func('callback should not run'));
	// Verify the request is enqueued:
	const state = await navigator.locks.query();
	assert_equals(state.held.filter(lock => lock.name === res).length, 1);
	assert_equals(state.pending.filter(lock => lock.name === res).length, 1);
	const rejected = promise_rejects(
	t, 'AbortError', promise, 'Request should reject with AbortError');
	controller.abort();
	await rejected;
	}, 'An aborted request results in AbortError');

wpt/web-locks/signal.tentative.https.any.js

Lines 65 to 94 in 7d538d1

	promise_test(async t => {
	const res = uniqueName(t);
	// Grab a lock and hold it forever.
	const never_settled = new Promise(resolve => { /* never */ });
	navigator.locks.request(res, lock => never_settled);
	const controller = new AbortController();
	const promise =
	navigator.locks.request(res, {signal: controller.signal}, lock => {});
	// Verify the request is enqueued:
	const state = await navigator.locks.query();
	assert_equals(state.held.filter(lock => lock.name === res).length, 1);
	assert_equals(state.pending.filter(lock => lock.name === res).length, 1);
	const rejected = promise_rejects(
	t, 'AbortError', promise, 'Request should reject with AbortError');
	let callback_called = false;
	t.step_timeout(() => {
	callback_called = true;
	controller.abort();
	}, 10);
	await rejected;
	assert_true(callback_called, 'timeout should have caused the abort');
	}, 'Abort after a timeout');

The test came from #12449 / #12860 by @inexorabletash and reviewed by @pwnall.

[foolip]

With #15016 applied one can tell that it is the second assert_equals in each subtest that fails, the one for state.pending.filter(lock => lock.name === res).length.

That it's so consistently 5/10 failing and a length 2 instead of 1 suggests that this isn't the random variety of flakiness, but an interaction or state dependency that consistently happens if the tests are run in this way.

By guess is that the uniqueName helped isn't producing globally unique names and that two instances of the test are running in the same browser at the same time. That would at least produce something like this failure.