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

Simplify IBC app callback lookup #3817

Closed
3 tasks
colin-axner opened this issue Jun 12, 2023 · 3 comments
Closed
3 tasks

Simplify IBC app callback lookup #3817

colin-axner opened this issue Jun 12, 2023 · 3 comments
Labels
needs discussion Issues that need discussion before they can be worked on nice-to-have type: code hygiene Clean up code but without changing functionality or interfaces
Milestone

Comments

@colin-axner
Copy link
Contributor

Summary

Simplify the application callback lookup

Problem Definition

Currently the msg_server.go performs a repetitive calls to LookupModuleByPort and LookupModuleByChannel. These function are only used to get the module which is then passed to k.Router.GetRoute(module) to obtain the application callbacks.

Currently some of the calls to these lookup function use the returned capability, but this will likely be removed after this spec issue is addressed.

Proposal

We can likely reduce this 2 step lookup into one call:

cbs, err := k.PortKeeper.LookupCallbacksByChannel(ctx, msg.PortId, msg.ChannelId)
If err != nil {
    return err
}

Another alternative is to have the port keeper implement each callback function, such that you call through the port keeper:

err := k.PortKeeper.OnChanInit()

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@colin-axner colin-axner added needs discussion Issues that need discussion before they can be worked on nice-to-have type: code hygiene Clean up code but without changing functionality or interfaces labels Jun 12, 2023
@DimitrisJim
Copy link
Contributor

DimitrisJim commented Jun 12, 2023

I was wondering about this yesterday while looking at the ChannelUpgradeTry PR.

I can see the benefit in LookupCallbackByChannel in that it would keep the current requirement to get the capability localized and facilitate an easier transition. (Apart from the obvious code duplication savings).

What would be the proposed operation of OnChanInit? Would it offer any benefits over the other approach? Wouldn't it require adding an additional function on PortKeeper for all handlers? These functions are available to all applications so having these on PortKeeper might make it additionally confusing.

Just some initial thoughts.

@colin-axner
Copy link
Contributor Author

What would be the proposed operation of OnChanInit? Would it offer any benefits over the other approach? Wouldn't it require adding an additional function on PortKeeper for all handlers? These functions are available to all applications so having these on PortKeeper might make it additionally confusing.

I agree, because of the size of the IBC app interface, it could become confusing. The main benefit is that the concept of app callback lookup becomes internal to the port keeper rather than being invoked by the msgs associated with the channel keeper. The msg server handler would become a lot simpler as they would simply perform 04-channel logic and then directly call the On callbacks via the port keeper without callback lookup

@colin-axner
Copy link
Contributor Author

Closed by latest upstreaming of capability removal!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion Issues that need discussion before they can be worked on nice-to-have type: code hygiene Clean up code but without changing functionality or interfaces
Projects
Status: Done 🥳
Development

Successfully merging a pull request may close this issue.

3 participants