-
Notifications
You must be signed in to change notification settings - Fork 122
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
Decide if IBC err acks are important #568
Comments
Related to this, if IBC err acks are deemed to be neccessary. There are additional places we could return them when something goes wrong. Namely, VSCMatured packets could be validated upon being recv, and return an IBC err ack if there is something invalid with the vscID Note: this would require logic and/or additional state to determine what makes a vscID invalid. There's not any sensible stateless validation we can make AFAIK |
Doesn't an error ack close the channel? |
Message from @colin-axner
|
AFAIK, not in the IBC module. Only if we close it on the application side (i.e., in the OnAck code). |
Let's check. I think a while ago in a WIP PR I accidentally returned an error and it automatically closed the channel. |
Problem
#542 makes it more explicit for which cases we return an IBC err ack when a slash packet is recv. However, we could simplify a lot of code if we do not return IBC err acks in any case, and always drop slash packets when there is something wrong with the data. This warrants a larger question, how much does it matter whether or not we return IBC err acks? Does this affect anything?
Should relayers be aware of the fact that they are relaying invalid packets? There are some cases that we currently silently fail slash packets for example, without a relayer being aware of such silent failures
CC @mpoke
Closing criteria
Decide if IBC err acks are important, act accordingly
The text was updated successfully, but these errors were encountered: