-
Notifications
You must be signed in to change notification settings - Fork 20.2k
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
les, tests: fix les clientpool #22756
Conversation
4654005
to
46d2c62
Compare
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.
lgtm
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.
See comment, it's not 100% correct but works for our current use cases so it's safe to merge now to get rid of the fuzzer error.
@@ -239,12 +239,11 @@ func (cp *ClientPool) SetCapacity(node *enode.Node, reqCap uint64, bias time.Dur | |||
maxTarget = curve.maxCapacity(func(capacity uint64) int64 { | |||
return balance.estimatePriority(capacity, 0, 0, bias, false) | |||
}) | |||
if maxTarget <= capacity { | |||
if maxTarget < reqCap { |
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.
Actually this is not really correct, with this change SetCapacity
cannot do a partial capacity increase. maxTarget
is the highest available capacity according to the curve based estimation. If it's somewhere between current capacity
and reqCap
then we should not exit, we should still attempt requestCapacity
.
Still, since we don't use partial capacity increase yet (SetCapacity
is only accessible from the API right now), you can merge this PR as it is if the fuzzer error is annoying and I'll figure out a really robust method later.
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.
Hmm. I don't know. Perhaps a simple solution for this scenario is that the server can respond the current available capacity to the client and client needs to re-request the capacity with a lower target.
But let's see how will this partial capacity work.
* les, tests: fix les clientpool * tests: disable debug mode * les: polish code
No description provided.