-
Notifications
You must be signed in to change notification settings - Fork 8
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
Improve hub locking #1694
Improve hub locking #1694
Conversation
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.
Great job. A few questions though.
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've reviewed about half of it, I still have a few files to go through, but here's the first batch of comments :-)
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.
Much better, and it's allowed me to spot a few other issues for future PRs :)
We're on the right path !
} | ||
|
||
if currentState { | ||
return xerrors.Errorf("query with id %d already answered", id) |
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.
Just realized something, completely outside the scope of this PR.
This error propagates all the way to the socket.
So if another peer (for whatever reason) sends the "answer" message twice, they will get an error in return saying "we've already gotten your answer".
Is this something that would need to be shared with the other peer, or just logged ?
What would the other peer be expected to do - retry ? That would likely make things worse (infinite loop of errors / retries)
It seems manageable (in this case) to implement some degree of idempotency.
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 agree that we should just log it because we wouldn't expect the peer to do anything. I think it could be a nice first issue so I'll add it to the repo (#1709). Regarding idempotency, would that also apply to when we try to create a channel that was already created ? Currently we send a "duplicate resource" error but how do we differentiate between cases that warrant idempotency and those that don't ?
Unrelated to that but I also noticed that we don't always respect the protocol when it comes to sending errors back. Since we have many "levels" of returning in go, the nature of the error gets lost by the time it arrives to the method that's supposed to create the error to send back so we don't have the right code. Thankfully, we already have methods designed to create the right error with the right code but those aren't always used for some reason. I'll investigate the individual cases and open github issues for them. They're easy fixes but also a good way to get to know the codebase so they'll be good first issues as well.
[PoP - PoPCHA-Web-Client] Kudos, SonarCloud Quality Gate passed! |
[PoP - Be1-Go] Kudos, SonarCloud Quality Gate passed! |
[PoP - Be2-Scala] Kudos, SonarCloud Quality Gate passed! |
[PoP - Fe2-Android] Kudos, SonarCloud Quality Gate passed! |
[PoP - Fe1-Web] Kudos, SonarCloud Quality Gate passed! |
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.
As discussed, there are still some performance improvements possible, but this is already so much better than in the past.
Great job !
This PR aims to: