From 8693df46562069051b027f034c172b1e0d284574 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Kripalani?= Date: Sat, 24 Jul 2021 12:53:56 +0100 Subject: [PATCH] fix racy TestSimultanenousTransferLimit. --- itests/deals_concurrent_test.go | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/itests/deals_concurrent_test.go b/itests/deals_concurrent_test.go index 241c9071d..303a4e9c6 100644 --- a/itests/deals_concurrent_test.go +++ b/itests/deals_concurrent_test.go @@ -190,7 +190,21 @@ func TestSimultanenousTransferLimit(t *testing.T) { cancel() wg.Wait() - require.LessOrEqual(t, maxOngoing, graphsyncThrottle) + // The eventing systems across go-data-transfer and go-graphsync + // are racy, and that's why we can't enforce graphsyncThrottle exactly, + // without making this test racy. + // + // Essentially what could happen is that the graphsync layer starts the + // next transfer before the go-data-transfer FSM has the opportunity to + // move the previously completed transfer to the next stage, thus giving + // the appearance that more than graphsyncThrottle transfers are + // in progress. + // + // Concurrency (20) is x10 higher than graphsyncThrottle (2), so if all + // 20 transfers are not happening at once, we know the throttle is + // in effect. Thus we are a little bit lenient here to account for the + // above races and allow up to graphsyncThrottle*2. + require.LessOrEqual(t, maxOngoing, graphsyncThrottle*2) } runTest(t)