Test injection_queue_depth_multi_thread is flaky

[Darksonn]

This test has been observed to fail in CI:

tokio/tokio/tests/rt_unstable_metrics.rs

Lines 642 to 668 in 83e922f

	#[test]
	fn injection_queue_depth_multi_thread() {
	let rt = threaded();
	let metrics = rt.metrics();
	let barrier1 = Arc::new(Barrier::new(3));
	let barrier2 = Arc::new(Barrier::new(3));
	// Spawn a task per runtime worker to block it.
	for _ in 0..2 {
	let barrier1 = barrier1.clone();
	let barrier2 = barrier2.clone();
	rt.spawn(async move {
	barrier1.wait();
	barrier2.wait();
	});
	}
	barrier1.wait();
	for i in 0..10 {
	assert_eq!(i, metrics.injection_queue_depth());
	rt.spawn(async {});
	}
	barrier2.wait();
	}

To close this issue, figure out why it is failing and fix it.

[jofas]

I presume it's these two recent jobs that timed out

• https://github.com/tokio-rs/tokio/actions/runs/10820423666/job/30020516601

• https://github.com/tokio-rs/tokio/actions/runs/10718157570/job/29719516533

that have been affected by the flakiness of injection_queue_depth_multi_thread? I'd assume so because if this assert

tokio/tokio/tests/rt_unstable_metrics.rs

Line 663 in 83e922f

assert_eq!(i, metrics.injection_queue_depth());

fails, the main thread panics and we never get to synchronise on barrier2

tokio/tokio/tests/rt_unstable_metrics.rs

Line 667 in 83e922f

barrier2.wait();

here, causing the test to run forever (or until CI times out).

[Darksonn]

Yes. Good point with the assert. That explains why it times out instead of failing normally.

[jofas]

I wonder if a first step¹ would be to convert the assert into an if-statement where we'd panic only after calling barrier2.wait(). Then we'd get better diagnostics but more importantly wouldn't time out CI any more.

Footnotes

1. In case this isn't a quick fix ↩