Flaky test in `release-tests-windows` CI job

[jimmygchen]

https://github.com/sigp/lighthouse/actions/runs/15044891932/job/42284911795

This test appears to be flaky:

──── STDERR: lighthouse_network::rpc_tests test_delayed_rpc_response

thread 'test_delayed_rpc_response' panicked at beacon_node\lighthouse_network\tests\rpc_tests.rs:1229:33:
assertion failed: request_sent_at.elapsed() >
(Duration::from_secs(QUOTA_SEC) - Duration::from_millis(100))
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Here is the failing assertion:

lighthouse/beacon_node/lighthouse_network/tests/rpc_tests.rs

Lines 1226 to 1233 in 1324d3d

	// The second and subsequent responses are delayed due to the response rate-limiter on the receiver side.
	// Adding a slight margin to the elapsed time check to account for potential timing issues caused by system
	// scheduling or execution delays during testing.
	assert!(
	request_sent_at.elapsed()
	> (Duration::from_secs(QUOTA_SEC)
	- Duration::from_millis(100))
	);

Although it looks like it already has a 100ms margin added, which should probably be enough? Might need @ackintosh's help to figure out the right fix.

[jimmygchen]

Hi @ackintosh, would you mind taking a look at this one?
I'm not sure if adding more margin to the assertion is the right fix, just wanted to check with you if things are working correctly.

[ackintosh]

Stdout logging for the test has been enabled via #7506. The sequence diagram below shows what happened during the test run in which test_delayed_rpc_response failed.

The intent of test_delayed_rpc_response is to check that the rate-limiter is working on the receiver side in an end-to-end fashion. I think expanding the margin, to 500ms for example, would be a good idea.

[jimmygchen]

Fixed in #7522, thanks @ackintosh and @diegomrsantos for help with investigating! 🎉