-
Notifications
You must be signed in to change notification settings - Fork 72
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
Limit to single inflight package syncing operation #289
Limit to single inflight package syncing operation #289
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #289 +/- ##
==========================================
+ Coverage 76.32% 76.89% +0.56%
==========================================
Files 25 25
Lines 1681 1692 +11
==========================================
+ Hits 1283 1301 +18
+ Misses 291 285 -6
+ Partials 107 106 -1 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Paschalis Tsilias <[email protected]>
Signed-off-by: Paschalis Tsilias <[email protected]>
88b2071
to
8fec037
Compare
I've rebased main and fixed the conflict from a recent PR, let me know what you think! 🙌 |
Signed-off-by: Paschalis Tsilias <[email protected]>
Signed-off-by: Paschalis Tsilias <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor comments, mostly LGTM.
Signed-off-by: Paschalis Tsilias <[email protected]>
Signed-off-by: Paschalis Tsilias <[email protected]>
Signed-off-by: Paschalis Tsilias <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM
client/internal/httpsender_test.go
Outdated
}, | ||
} | ||
|
||
// Set the RequestInstanceUid flag on the tracked state to request the server for a new ID to use. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the catch, removing it.
Signed-off-by: Paschalis Tsilias <[email protected]>
… concurrent Signed-off-by: Paschalis Tsilias <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, I was out last week.
Signed-off-by: Paschalis Tsilias <[email protected]>
Signed-off-by: Paschalis Tsilias <[email protected]>
Signed-off-by: Paschalis Tsilias <[email protected]>
// Make sure that both Sync calls have gone through _before_ releasing the first one. | ||
// This means that they're both called in parallel, and that the race | ||
// detector would always report a race condition, but proper locking makes | ||
// sure that's not the case. | ||
assert.Eventually(t, func() bool { | ||
return messages.Load() == 2 | ||
}, 2*time.Second, 100*time.Millisecond, "both messages must have been processed successfully") | ||
|
||
// Release the second Sync call so it can continue and wait for both of them to complete. | ||
blockSyncCh <- struct{}{} | ||
<-doneCh[0] | ||
<-doneCh[1] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this makes sense now. Thanks!
Thanks for your patience @tpaschalis |
This PR revives work done in previous PRs (#118, #120) to make sure that only a single package syncing operation is ever in flight and also adds a test.
The previous PRs did not account for needing to also protect
initStatuses
andSetPackageStatuses
, so that's why the Lock and Unlock statements are not just paired in doSync. If you think the intent would be clearer using a sync.WaitGroup, let me know.The new test makes sure that the mutex correctly protects the local storage; if we comment out the calls to Lock/Unlock and run the test with the
-race
flag we can see the race condition taking placeFixes #84