-
Notifications
You must be signed in to change notification settings - Fork 43
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
refactor(participation
): use sdk.Int
type for allocations
#894
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #894 +/- ##
===========================================
- Coverage 10.56% 10.55% -0.01%
===========================================
Files 327 327
Lines 75110 75191 +81
===========================================
+ Hits 7936 7939 +3
- Misses 66984 67062 +78
Partials 190 190
|
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 catch!
We actually have a test case that checks with negative delegation and I may think it should have triggered the panic
and so triggering test failure.
Would it be possible to replace in total_allocation_test.go
, wantError bool
with a more accurate err error
and assert ErrorIs(...)
with ErrInvalidAddress
and ErrInvalidAllocationAmount
?
So we ensure the correct check if performed for negative value
Hey sorry to stick my nose here, but I really don't understand how a panic can happen when calling For instance Do you have the trace of the panic @aljo242 please ? |
An out of bound number would cause a panic. I would actually guess that the risk exist on both ends (so also a really big positive number) |
Indeed, so maybe you can also cover the big positive number case with an additional condition, wdyt ? |
Yes @tbruyelle , I hadn't fully understood the cause of the panic when I wrote this - apologies. I ran into a panic with a large negative number during simulation testing. Modifying this PR now ! |
This is very appreciated! My bad, I misread the method as well looking at the PR. My suggestion would be to refactor and remove completely the usage of |
Question, why do we deal with message QueryGetAvailableAllocationsResponse {
uint64 availableAllocations = 1;
} to represent something that can overlap (both |
It's because the protobuf encoding would be non-deterministic otherwise, that's the reason for using strings. Would be the same using bytes, I guess strings makes it easier also for reading the json equivalent.
Allocations cannot be negative, proper typing that scopes out the result prevents errors. The panic was due to an out-of-bound error, the fact that it was a negative number was just coincidental. A big positive number would have caused the same issue |
Thanks for the explanation @giunatale 🙏 Just a though about replacing |
Yes, it appears that the max bitlength for |
participation
): potential panic on keeper TotalAllocations functionparticipation
): use sdk.Int
type for allocations
Is this ready for review @aljo242 ? |
Ready for review. Thanks for the @tbruyelle ! |
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
What about also applying my first suggestion?
Would it be possible to replace in total_allocation_test.go, wantError bool with a more accurate err error and assert ErrorIs(...) with ErrInvalidAddress and ErrInvalidAllocationAmount?
So we ensure the correct check if performed for negative value
Co-authored-by: Thomas Bruyelle <thomas.bruyelle@gmail.com>
Co-authored-by: Lucas Btd <lucas.bertrand.22@gmail.com>
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.
We should fix genesis in localnet
The only changes should be to put requiredAllocations
values in spn/genesis_template.json
and testnet/genesis_template.json
in quotes as those are now sdk.Int
to be unmarshalled
What does this PR does?
Removes a potential panic when calling SDK
TruncateInt64
for theTotalAllocations()
query. An error is now returned before the panic can be reached.