Add extension point for ibc app version decoding #1100
Conversation
There was a problem hiding this comment.
I am confused here, and we should check with the ibc-go team.
When I discussed middleware with them this summer, understood it to be transparent. So if I have middleware(A) talking to middleware(B), neither A or B is aware they are wrapped by the middleware. The middleware sees the whole packet and version and after stripping off it's envelope, passes the content to the wrapped protocol.
For me, this is the only way that it can easily be adopted without forking all protocols that may be wrapped. Can @AdityaSripal comment on this issue?
|
The issue is that we not always have the full channel data passed via the IBC module but load the channel info from the store. There the raw version is stored. |
| }, | ||
| ) IBCAppVersionDecoder { | ||
| return AppVersionDecoderFn(func(ctx sdk.Context, rawVersion, portID, channelID string) (string, error) { | ||
| if channelSource.IsFeeEnabled(ctx, portID, channelID) { |
There was a problem hiding this comment.
If needed to get it to work, it is a hack and shows middleware stack is not complete.
There may be many new middleware and the wrapped applications shouldn't need to care, so no need to add eg ICS49 middleware that comes later
Codecov Report
@@ Coverage Diff @@
## 960_ibc420 #1100 +/- ##
==============================================
+ Coverage 59.87% 59.94% +0.07%
==============================================
Files 54 55 +1
Lines 7299 7332 +33
==============================================
+ Hits 4370 4395 +25
- Misses 2617 2621 +4
- Partials 312 316 +4
|
|
Obsolete by #1102 |
After #1088
The version string stored with the channel can be overloaded with ibc middleware data. This PR adds an extension point to add a custom decoder to return the original IBC app level version.