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

[Supplier] feat: persistence proofs in submit proof msg handler (2) #328

Merged
merged 52 commits into from
Feb 1, 2024

Conversation

bryanchriswhite
Copy link
Contributor

@bryanchriswhite bryanchriswhite commented Jan 17, 2024

Summary

Human Summary

Issue

Type of change

Select one or more:

  • New feature, functionality or library
  • Bug fix
  • Code health or cleanup
  • Documentation
  • Other (specify)

Testing

  • Run all unit tests: make go_develop_and_test
  • Run E2E tests locally: make test_e2e
  • Run E2E tests on DevNet: Add the devnet-test-e2e label to the PR. This is VERY expensive, only do it after all the reviews are complete.

Sanity Checklist

  • I have tested my changes using the available tooling
  • I have performed a self-review of my own code
  • I have commented my code, updated documentation and left TODOs throughout the codebase

@bryanchriswhite bryanchriswhite added supplier Changes related to the Supplier actor off-chain Off-chain business logic labels Jan 17, 2024
@bryanchriswhite bryanchriswhite added this to the Shannon TestNet milestone Jan 17, 2024
@bryanchriswhite bryanchriswhite self-assigned this Jan 17, 2024
@bryanchriswhite bryanchriswhite added on-chain On-chain business logic and removed off-chain Off-chain business logic labels Jan 17, 2024
@bryanchriswhite bryanchriswhite force-pushed the issues/141/refactor/proof-store-indices-2 branch from cce5a68 to 3665b5e Compare January 17, 2024 11:39
@bryanchriswhite bryanchriswhite force-pushed the issues/141/refactor/proof-store-indices-2 branch from 3665b5e to 08d68ab Compare January 17, 2024 11:44
@bryanchriswhite bryanchriswhite linked an issue Jan 23, 2024 that may be closed by this pull request
8 tasks
Copy link
Contributor

@h5law h5law left a 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!

e2e/tests/session.feature Show resolved Hide resolved
e2e/tests/session_steps_test.go Outdated Show resolved Hide resolved
e2e/tests/session_steps_test.go Outdated Show resolved Hide resolved
e2e/tests/session_steps_test.go Show resolved Hide resolved
@@ -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())
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


if err := msg.ValidateBasic(); err != nil {
return nil, err
return nil, status.Error(codes.InvalidArgument, err.Error())
Copy link
Contributor

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.

Copy link
Contributor Author

@bryanchriswhite bryanchriswhite Jan 25, 2024

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())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return sdkerrors.Wrapf(ErrSupplierInvalidAddress, "%s", msg.GetSupplierAddress())
return ErrSupplierInvalidAddress.Wrapf("%s", msg.GetSupplierAddress())

Same for all the others

Copy link
Contributor Author

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.

Copy link
Contributor Author

@bryanchriswhite bryanchriswhite Jan 25, 2024

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:

image

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.

Copy link
Contributor Author

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(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return sdkerrors.ErrInvalidAddress.Wrapf(
return ErrSupplierInvalidAddress.Wrapf(

I think you should define this type something like invalid supplier address

Copy link
Contributor Author

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).

Copy link
Contributor Author

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?"

x/supplier/types/message_submit_proof.go Outdated Show resolved Hide resolved
},
Proof: testClosestMerkleProof,
},
expectedErr: sdkerrors.ErrInvalidAddress.Wrapf(
Copy link
Contributor

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

Copy link
Contributor Author

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)).

Copy link
Member

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

e2e/tests/session_steps_test.go Outdated Show resolved Hide resolved
x/supplier/keeper/msg_server_submit_proof.go Show resolved Hide resolved
x/supplier/keeper/msg_server_submit_proof.go Show resolved Hide resolved
bryanchriswhite and others added 2 commits January 25, 2024 10:39
Co-authored-by: h5law <[email protected]>
Co-authored-by: Daniel Olshansky <[email protected]>
Co-authored-by: Redouane Lakrache <[email protected]>
bryanchriswhite and others added 2 commits January 25, 2024 11:10
Co-authored-by: Daniel Olshansky <[email protected]>
Co-authored-by: h5law <[email protected]>
…ersistence-2

* pokt/main:
  Update upload-pages-artifact.yml
  Update upload-pages-artifact.yml (#346)
  Fix upload-pages-artifact.yml (#345)
  [Service] Add AddServiceFee and enforce it in the message handler (#337)
@bryanchriswhite bryanchriswhite force-pushed the issues/141/feat/proof-persistence-2 branch from fa3a6e0 to 49888cd Compare January 25, 2024 10:11
Copy link
Member

@Olshansk Olshansk left a 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.

@Olshansk Olshansk merged commit 1b4a8d5 into main Feb 1, 2024
9 checks passed
@bryanchriswhite bryanchriswhite removed push-image CI related - pushes images to ghcr.io devnet-test-e2e labels May 16, 2024
@github-actions github-actions bot removed the devnet label May 16, 2024
okdas pushed a commit that referenced this pull request Nov 14, 2024
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on-chain On-chain business logic supplier Changes related to the Supplier actor
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

[Protocol] MVP implementation off the on-chain SubmitProof message handling
4 participants