-
Notifications
You must be signed in to change notification settings - Fork 404
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 wasm message handlers and query plugin #460
Conversation
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 nice. And cool trick with the chaining and ErrUnknownMsg
Codecov Report
@@ Coverage Diff @@
## master #460 +/- ##
==========================================
+ Coverage 55.48% 56.88% +1.39%
==========================================
Files 39 40 +1
Lines 4318 4356 +38
==========================================
+ Hits 2396 2478 +82
+ Misses 1721 1674 -47
- Partials 201 204 +3
|
}) | ||
} | ||
|
||
// WithMessageHandler is an optional constructor parameter to set a custom message handler. | ||
// WithMessageHandler is an optional constructor parameter to set a custom handler for wasmVM messages. |
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.
Not a blocker, but an idea for the future.
Now that we chain the handlers, most customizations (outside of tests) would likely be prepending or appending something to the default chain. This should be easy to do.
Right now, making a new chain like the default is exposed as public constructors
return NewMessageHandlerChain(
NewSDKMessageHandler(router, encoders),
NewIBCRawPacketHandler(channelKeeper, capabilityKeeper),
)
But it does require the router, and various keepers to construct it. Those are not exposed on the keeper, we could only extend the default if we do that in app.go
where we have the keepers, or some other code that wraps the constuctor of the keeper. Maybe that is the only place it would make sense to customize the handler, but just thinking....
If this makes sense to you, please open a future issue to allow appending/prepending to the default chain. If you think this is do-able with the current API, then I am fine.
Use case: if there is something I cannot express as an Encoder and I want to add support for that Custom message, I want to be able to extend this.
This is a refactoring within the wasmvm message handling components and queries.
Design goal was to
nil
instantiation parameters for default pluginsNew
Options
as extension points:WithMessageHandler
- replace default message handlerWithQueryHandler
- replace default query handlerWithMessageEncoders
- replace default encodersWithQueryPlugins
- replace default query plugins