retry only if processing completed for a packet #1393
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
relayer/relayer/processor/message_processor.go
Line 323 in be5a4cf
here we track the height where we are "processing" a message. This is prior to attempting the broadcas
relayer/relayer/processor/path_end_runtime.go
Line 580 in be5a4cf
here, we check if the number of blocks since the
lastProcessedHeight
is at least 5, and will retry if so.So, if we broadcast and don't see the observed event within 5 blocks, it will retry. This is especially an issue on faster chains such as sei and dydx where tx propagation through the p2p network can take more than 5 blocks
This modifies the behavior to be: if the last attempted broadcast completed, then retry if it has been more than 5 blocks since the previous broadcast attempt.
Additionally:
removePacketRetention
was using the incorrect key for clearing caches on the counterparty, which for acks can lead to counterparty recvpackets not being cleared.Related: #1359