Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix racy TestSimultanenousTransferLimit. #6862

Merged
merged 2 commits into from
Jul 26, 2021
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion itests/deals_concurrent_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down