Asynchronous acknowledgements #480
Conversation
|
.... the PDF creation issue seems to be specific to my setup, perhaps an Arch Linux upgrade issue. |
|
Still trying to fix PDF creation but the spec changes are ready for review. |
Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com>
| @@ -565,15 +571,14 @@ The IBC handler performs the following steps in order: | |||
| - Checks that the packet sequence is the next sequence the channel end expects to receive (for ordered channels) | |||
| - Checks that the timeout height has not yet passed | |||
| - Checks the inclusion proof of packet data commitment in the outgoing chain's state | |||
| - Sets the opaque acknowledgement value at a store path unique to the packet (if the acknowledgement is non-empty or the channel is unordered) | |||
| - Sets a store path to indicate that the packet has been received (unordered channels only) | |||
There was a problem hiding this comment.
Don't we need to set recvPacket all the time now? As we do not rely on acknowledgements?
If a synchronous acknowledgement obviates the need for recvPacket then this should specify that either acknowledgement or receipt must be written atomically with onRecv.
Or maybe you can explain why I misunderstand this.
There was a problem hiding this comment.
recvPacket always needs to be called, as usual, regardless of whether or not an acknowledgement will be written.
|
This build issue seems to be related to sergiocorreia/panflute#142; downgrading my |
Closes #478
writeAcknowledgementfunctionmakeprocess (somehow broken)