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

Review work on on ADR 15 #5546

Closed
cwgoes opened this issue Jan 21, 2020 · 8 comments
Closed

Review work on on ADR 15 #5546

cwgoes opened this issue Jan 21, 2020 · 8 comments
Assignees

Comments

@cwgoes
Copy link
Contributor

cwgoes commented Jan 21, 2020

From this comment onwards - #5401 (comment)

@mossid
Copy link
Contributor

mossid commented Jan 29, 2020

#5401 (comment)

Sequence increasing is now happening inside PacketExecuted which is called by the handlers

@fedekunze fedekunze added this to the IBC Implementation milestone Jan 29, 2020
@mossid
Copy link
Contributor

mossid commented Jan 29, 2020

#5401 (comment)

It should be called by the receiving side of the connection(in the ICS20 handler), will check it once more

WriteAcknowledgement should be called by the receipt handler

@mossid
Copy link
Contributor

mossid commented Jan 29, 2020

#5401 (comment)

That seems like a mistake.... can be fixed by using a cachecontext inside the antehandler, keep increasing sequence, but not writing back to the underlying store...

@cwgoes
Copy link
Contributor Author

cwgoes commented Jan 29, 2020

#5401 (comment)

That seems like a mistake.... can be fixed by using a cachecontext inside the antehandler, keep increasing sequence, but not writing back to the underlying store...

OK, I am not entirely sure what you mean, can you write it in a PR perhaps? (ditto for the above)

@fedekunze
Copy link
Collaborator

WriteAcknowledgement should be called by the receipt handler

what is the receipt handler?

@fedekunze
Copy link
Collaborator

@cwgoes:

I am trying to figure out what is intended here. It looks like you want the ante handler to check the sequence @mossid, but if we write the sequence only when packets are executed that won't work for subsequent packets in the same block (since the ante handler will be executed first). What is intended?
For now, I added the check in RecvPacket() and the write in PacketExecuted() - this will work for the test cases & in simple cases, but I don't think this is the right solution long-term.

in the case of multiple packet executions, are all of them atomic, i.e should we revert any change if one of those executions fail?

@cwgoes
Copy link
Contributor Author

cwgoes commented Jan 31, 2020

in the case of multiple packet executions, are all of them atomic, i.e should we revert any change if one of those executions fail?

For now, I think we should maintain the atomicity semantics of multi-Msg transactions, but subject to separate acknowledgement/failure handling as defined by the IBC spec (so a "ack of failure" would cause remaining packets to be processed, but an invalid sequence would cause remaining packets to fail & all state changes to be reverted). Does that make sense?

@cwgoes cwgoes assigned cwgoes and unassigned mossid Feb 4, 2020
@cwgoes
Copy link
Contributor Author

cwgoes commented Feb 18, 2020

I don't think there are any remaining actionables here. @mossid if there are please open issues.

@cwgoes cwgoes closed this as completed Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants