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

refactor(participation): use sdk.Int type for allocations #894

Merged
merged 17 commits into from
Jul 26, 2022

Conversation

aljo242
Copy link
Contributor

@aljo242 aljo242 commented Jul 17, 2022

What does this PR does?

Removes a potential panic when calling SDK TruncateInt64 for the TotalAllocations() query. An error is now returned before the panic can be reached.

@aljo242 aljo242 self-assigned this Jul 17, 2022
@aljo242 aljo242 requested a review from giunatale as a code owner July 17, 2022 18:54
@codecov
Copy link

codecov bot commented Jul 17, 2022

Codecov Report

Merging #894 (663509b) into develop (e185661) will decrease coverage by 0.00%.
The diff coverage is 13.46%.

Impacted file tree graph

@@             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              
Impacted Files Coverage Δ
...participation/types/auction_used_allocations.pb.go 1.20% <0.00%> (-0.05%) ⬇️
x/participation/types/events.pb.go 0.86% <0.00%> (-0.03%) ⬇️
x/participation/types/params.pb.go 0.70% <0.00%> (-0.02%) ⬇️
x/participation/types/query.pb.go 0.67% <0.00%> (-0.01%) ⬇️
x/participation/types/used_allocations.pb.go 1.49% <0.00%> (-0.08%) ⬇️
x/participation/keeper/msg_withdraw_allocations.go 83.78% <50.00%> (ø)
x/participation/keeper/available_allocations.go 100.00% <100.00%> (ø)
x/participation/keeper/grpc_used_allocations.go 86.04% <100.00%> (ø)
x/participation/keeper/msg_participate.go 100.00% <100.00%> (ø)
x/participation/keeper/total_allocations.go 100.00% <100.00%> (ø)
... and 10 more

Copy link
Contributor

@lumtis lumtis left a 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

@tbruyelle
Copy link
Contributor

tbruyelle commented Jul 21, 2022

Hey sorry to stick my nose here, but I really don't understand how a panic can happen when calling TruncateInt64() on a negative number.

For instance sdk.NewDec(-1).TruncateInt64() doesn't trigger any panic and just returns -1.

Do you have the trace of the panic @aljo242 please ?

@giunatale
Copy link
Contributor

giunatale commented Jul 21, 2022

Hey sorry to stick my nose here, but I really don't understand how a panic can happen when calling TruncateInt64() on a negative number.

For instance sdk.NewDec(-1).TruncateInt64() doesn't trigger any panic and just return -1.

Do you have the trace of the panic @aljo242 please ?

-1 is ok, but the panic risk do indeed exist. This is visible when looking at the source:
https://github.com/cosmos/cosmos-sdk/blob/main/math/dec.go#L676

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)

@tbruyelle
Copy link
Contributor

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 ?

@aljo242
Copy link
Contributor Author

aljo242 commented Jul 21, 2022

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 !

@lumtis
Copy link
Contributor

lumtis commented Jul 21, 2022

Hey sorry to stick my nose here

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 uint64 and changing the logic of the module to use sdk.Int

@tbruyelle
Copy link
Contributor

tbruyelle commented Jul 21, 2022

Question, why do we deal with uint64 in query response like

message QueryGetAvailableAllocationsResponse {
  uint64 availableAllocations = 1;
}

to represent something that can overlap int64 (I assume this was the reason of the panic). Why not a simple string ?
I noticed that strings are often used in the cosmos-sdk to represent numbers, it is to mitigate overlapping, right?

(both sdk.Dec and sdk.Int marshal into string)

@giunatale
Copy link
Contributor

giunatale commented Jul 21, 2022

I noticed that strings are often used in the cosmos-sdk to represent numbers, it is to mitigate overlapping, right?

(both sdk.Dec and sdk.Int marshal into string)

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.

Question, why do we deal with uint64 in query response

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

@tbruyelle
Copy link
Contributor

tbruyelle commented Jul 21, 2022

Thanks for the explanation @giunatale 🙏

Just a though about replacing uint64 by sdk.Int in the return of GetTotalAllocations: it seems like the conversion from sdk.Dec to sdk.Int can still trigger a panic if the underlying big.Int is out of some specific bounds (see sdk.Dec.TruncateInt()). Not sure if this is the same bounds than in sdk.Dec.TruncateInt64 that said.

@aljo242
Copy link
Contributor Author

aljo242 commented Jul 21, 2022

Thanks for the explanation @giunatale pray

Just a though about replacing uint64 by sdk.Int in the return of GetTotalAllocations: it seems like the conversion from sdk.Dec to sdk.Int can still trigger a panic if the underlying big.Int is out of some specific bounds (see sdk.Dec.TruncateInt()). Not sure if this is the same bounds than in sdk.Dec.TruncateInt64 that said.

Yes, it appears that the max bitlength for sdk.Int is 256 as opposed to 64, so we at least have larger bounds to operate within.

@aljo242 aljo242 changed the title fix(participation): potential panic on keeper TotalAllocations function refactor(participation): use sdk.Int type for allocations Jul 21, 2022
@lumtis
Copy link
Contributor

lumtis commented Jul 21, 2022

Is this ready for review @aljo242 ?

@aljo242
Copy link
Contributor Author

aljo242 commented Jul 21, 2022

Ready for review. Thanks for the @tbruyelle !

Copy link
Contributor

@lumtis lumtis left a 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

testutil/networksuite/networksuite.go Outdated Show resolved Hide resolved
testutil/sample/participation.go Outdated Show resolved Hide resolved
Co-authored-by: Thomas Bruyelle <thomas.bruyelle@gmail.com>
Alex Johnson and others added 2 commits July 22, 2022 13:42
Co-authored-by: Lucas Btd <lucas.bertrand.22@gmail.com>
@aljo242 aljo242 requested a review from lumtis July 22, 2022 17:59
Copy link
Contributor

@lumtis lumtis left a 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

@aljo242 aljo242 requested a review from lumtis July 25, 2022 13:00
tbruyelle
tbruyelle previously approved these changes Jul 25, 2022
@lumtis lumtis merged commit f310279 into develop Jul 26, 2022
@lumtis lumtis deleted the fix/total-allocations-panic branch July 26, 2022 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants