bug: SeaSolver timeout

[sunce86]

Problem

SeaSolver reported receiving lower time_limit parameter.
Right now, usually the value varies between 9-11s, while there are sometimes time limits of 7s or 6s.

One weird thing I noticed is this log:
https://production-6de61f.kb.eu-central-1.aws.cloud.es.io/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-24h%2Fh,to:now))&_a=(columns:!(log),filters:!(),index:c0e240e0-d9b3-11ed-b0e6-e361adffce0b,interval:auto,query:(language:kuery,query:'log:%20%228209421%22%20and%20%22seasolver%22'),sort:!(!('@timestamp',desc)))

External solvers should allocate 0.9 percent of available deadline for solving. SeaSolver timed out in this example, but still was left with 3.35s for the postprocessing? In the best case, it should be 15s * 0.1s = 1.5s.

Impact

External solvers less time for solving and timing out.

[fleupold]

There is another 500ms network delay in the driver (code) + 1s network delay in the legacy solver (code), but yeah things still look a bit off

[fleupold]

It was an issue with our configuration.

[fleupold]

Turns out the issue still doesn't seem resolved.

[fleupold]

Example logs: https://production-6de61f.kb.eu-central-1.aws.cloud.es.io/app/r/s/Jjjnt

[fleupold]

I think I found the issue. During prioritisation we share the entire auction struct across threads, which includes the deadline

services/crates/driver/src/domain/competition/auction.rs

Lines 151 to 167 in ddeb9b9

	let fut = tokio::task::spawn_blocking(move || {
	let start = std::time::Instant::now();
	Self::sort(&mut auction);
	let mut balances =
	rt.block_on(async { Self::fetch_balances(&eth, &auction.orders).await });
	Self::filter_orders(&mut balances, &mut auction.orders, &eth);
	tracing::debug!(auction_id = new_id.0, time =? start.elapsed(), "auction preprocessing done");
	Arc::new(auction)
	})
	.map(|res| {
	res.expect(
	"Either runtime was shut down before spawning the task or no OS threads are \
	available; no sense in handling those errors",
	)
	})
	.boxed()
	.shared();

Thus all auctions end up having the same deadline (the one of the first processed solver), which happens to be a solver with 80% solving time.