-
Notifications
You must be signed in to change notification settings - Fork 12
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
[Supplier] feat: persistence proofs in submit proof msg handler (2) #328
Conversation
Co-authored-by: Daniel Olshansky <[email protected]>
cce5a68
to
3665b5e
Compare
3665b5e
to
08d68ab
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.
Nice work, looks great - saw a pattern for error handling in messages emerge left some comments on that but overall this is coming along great!
@@ -25,7 +28,7 @@ func (k msgServer) CreateClaim(goCtx context.Context, msg *suppliertypes.MsgCrea | |||
msg.GetSupplierAddress(), | |||
) | |||
if err != nil { | |||
return nil, err | |||
return nil, status.Error(codes.InvalidArgument, err.Error()) |
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.
Is this something we should be doing in message handlers, over returning an error from types/errors.go
? Or is it specific for this use case that we are not doing so?
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: #328 (comment))
|
||
if err := msg.ValidateBasic(); err != nil { | ||
return nil, err | ||
return nil, status.Error(codes.InvalidArgument, err.Error()) |
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.
This seems like a pattern you have found, is it worth updating the codebase post migration to do this for all message handlers? Should we create an issue for this?
It looks like it stops us from using require.ErrorIs
/ require.ErrorAs
so some tests will need to be updated too.
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.
The CLI should ALWAYS return a gRPC status error (i.e. status.Error(...)
). In addition to consistency, this is an important aspect of separating client-facing errors from internal errors. Details of internal errors should only appear in logs that the operator sees and NEVER be sent to the client to avoid leaking potentially sensitive information.
This pattern fell out of the refactoring that was necessary in #266/#250. The tests in those branches take this into consideration (and will be re-applied in subsequent work).
IIRC the reason I pushed usage of status.Error
all the way down into the keeper was because there was a lot of redundancy appearing in the CLI code involving wrapping keeper errors in the same status code error. Given that the only consumer of the keepers should be the CLI, or one another, it didn't seem inappropriate to make that simplification. I don't have a strong opinion about it though.
if err != nil { | ||
return sdkerrors.Wrapf(ErrSupplierInvalidAddress, "invalid supplierAddress address (%s)", err) | ||
return sdkerrors.Wrapf(ErrSupplierInvalidAddress, "%s", msg.GetSupplierAddress()) |
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.
return sdkerrors.Wrapf(ErrSupplierInvalidAddress, "%s", msg.GetSupplierAddress()) | |
return ErrSupplierInvalidAddress.Wrapf("%s", msg.GetSupplierAddress()) |
Same for all the others
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 calling this out! 🙌
I thought I got all of these but I either missed some or there were some reversions between the cherry-picking, etc.
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.
After looking into this for second:
It seems like we have lots of usages of sdkerrors.Wrapf()
across the modules (none of which are in tests). This leads me to believe that we might have picked this up from the ignite generator templates (in whatever ignite version was used).
I would prefer to batch this out in a separate PR after v0.50 migration, in case we do decide to transplant regenerate module code.
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.
Captured in #347.
if err != nil { | ||
return sdkerrors.Wrapf(sdkerrors.ErrInvalidAddress, "invalid supplierAddress address (%s)", err) | ||
return sdkerrors.ErrInvalidAddress.Wrapf( |
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.
return sdkerrors.ErrInvalidAddress.Wrapf( | |
return ErrSupplierInvalidAddress.Wrapf( |
I think you should define this type something like invalid supplier address
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 created #348 to capture the higher-level concerns that I see as in play here.
In this particular case, my rationale for using sdkerrors.ErrInvalidAddress
over any of our own error variables is that the usage here is identical to that of the what I interpreted as its intended usage, as indicated by its actual usage in cosmos-sdk code (i.e. in cases where sdk.AccAddressFromBech32()
returns an error in #ValidateBasic()
methods).
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 could imagine a middle-of-the-road alternative as us defining an alias to that error, such that we reference the alias instead. However, this begs the question, "in which module should that error variable be defined?"
}, | ||
Proof: testClosestMerkleProof, | ||
}, | ||
expectedErr: sdkerrors.ErrInvalidAddress.Wrapf( |
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 the messages above about defining a type for this specific to the supplier module
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.
This must match whatever error variable we decide to go with in the above. Let's continue the conversation there (#328 (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.
Last minor set of comments in addition to those left by others
Co-authored-by: h5law <[email protected]> Co-authored-by: Daniel Olshansky <[email protected]>
Co-authored-by: Redouane Lakrache <[email protected]>
Co-authored-by: Daniel Olshansky <[email protected]> Co-authored-by: h5law <[email protected]>
fa3a6e0
to
49888cd
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.
Looks good from my end!
I know @h5law has some open comments for current/future work, so definitely should wait for a 👍 from his end as well.
…328) - Validate and persist proofs received in `MsgSubmitProof` message by the supplier module. - ~~Simplify `ReplayEventsClient` to reduce number of generic parameters~~ *(merged in #330)* --- Co-authored-by: Daniel Olshansky <[email protected]> Co-authored-by: Redouane Lakrache <[email protected]> Co-authored-by: h5law <[email protected]> Co-authored-by: h5law <[email protected]>
Summary
Human Summary
MsgSubmitProof
message by the supplier module.SimplifyReplayEventsClient
to reduce number of generic parameters(merged in [Off-chain] Simplify
TxClient
withEventsQueryClient
#330)Issue
SubmitProof
message handling #141Type of change
Select one or more:
Testing
make go_develop_and_test
make test_e2e
devnet-test-e2e
label to the PR. This is VERY expensive, only do it after all the reviews are complete.Sanity Checklist