-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Async Ack Fixes #7735
Async Ack Fixes #7735
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7735 +/- ##
==========================================
- Coverage 54.34% 54.13% -0.21%
==========================================
Files 610 610
Lines 38627 38848 +221
==========================================
+ Hits 20990 21029 +39
- Misses 15493 15671 +178
- Partials 2144 2148 +4 |
@@ -94,31 +94,31 @@ | |||
} | |||
}, | |||
{ | |||
"url": "./tmp-swagger-gen/ibc/channel/query.swagger.json", | |||
"url": "./tmp-swagger-gen/ibc/core/channel/v1/query.swagger.json", |
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.
This misconfiguration is why proto-swagger-gen
errored
// packet commitments, acknowledgments, and receipts | ||
// Caller is responsible for knowing the context necessary to interpret this | ||
// state as a commitment, acknowledgement, or a receipt | ||
message PacketState { |
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.
PacketAckCommitment
was a confusing name, changed it to PacketState
with docs
repeated PacketState acknowledgements = 2 | ||
[(gogoproto.casttype) = "PacketState", (gogoproto.nullable) = false]; | ||
repeated PacketState commitments = 3 [(gogoproto.nullable) = false]; | ||
repeated PacketState receipts = 4 [(gogoproto.nullable) = false]; |
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.
We did not include receipts in GenesisState 😱
// list of commitment sequences | ||
repeated uint64 packet_commitment_sequences = 3; | ||
// list of acknowledgment sequences | ||
repeated uint64 packet_ack_sequences = 3; | ||
} | ||
|
||
// QueryUnrelayedAcksResponse is the response type for the |
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.
Personally believe QueryUnrelayedAcks
should be renamed to QueryUnreceivedAcks
since this should be sent to original sending chain which is waiting to receive acks
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.
Isn't it a RPC sent to the chain writing acknowledgements? see previous discussion
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.
I was wrong back then. Definitely this RPC is meant to go to the chain receiving acknowledgements since that is the original sender chain which still has packet commitments in it if ack hasn't been received
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.
Renamed it along with docs, please double check the implementation to confirm my thinking here.
QueryUnreceivedAcks is being passed in a list of ack sequences and it will then check if the executing chain still has a packet commitment for that sequence. If it does, then the sequence is added to unreceived acks. Thus, the executing chain must be the original sender since it stores the packet commitments
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.
Sorry for the flipflop!! Hopefully the last change!
does this fix #7651? |
Yes it does |
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.
I think the discussion we had previously notes pros/cons for doing unrelayed acks vs unreceived acks. I don't have strong opinions since this is entirely a helper function for the relayer, so whatever would make it easiest. The relayer should also primarily rely on event streaming since received packets may never have a written ack
I do think the point I made last time makes a lot of sense for using unrelayed acks
How does a relayer determine which acknowledgement sequences to send? Unlike packet commitments, acknowledgements live forever so a relayer would have to already know which acknowledgements have not been acknowledged on the original chain, which is the purpose of this function.
Maybe that doesn't change anything. As long as this helps the relayer then LGTM
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.
ACK but see comments (and previous ones)
Co-authored-by: Federico Kunze <[email protected]> Co-authored-by: colin axnér <[email protected]>
Description
Asynchronous acks had a number of issues in it:
Other issue involved swagger files not being updated because of incorrect config
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes