-
Notifications
You must be signed in to change notification settings - Fork 332
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
Unambiguous packet query #613
Conversation
Before, a `query_txs` for a packet on a given chain would filter only by the packet source port, source channel and sequence. With 2 chains, there can be at most a single packet matching such filter, and this fact was assumed in the code. However, this assumption does not hold with more than 2 chains. To understand why, consider the following example with chains `ibc-0`, `ibc-1` and `ibc-2`: - a channel handshake occurs between `ibc-0` and `ibc-1`; the channel identifiers are `channel-0` on both ends - a channel handshake occurs between `ibc-1` and `ibc-2`; the channel identifier on `ibc-1` is `channel-1` and on `ibc-2` is `channel-0` If now both `ibc-0` and `ibc-2` send packets to `ibc-1` and we do a packet query filtering only by the source, such query will return packets from both `ibc-0` and `ibc-1` (as both have `channel-0` as the source channel in their packets). In this commit, we start filtering also by the destination port and destination channel. This makes the packet query unambiguous.
I left a TODO to make this assumption explicit. It will be addressed in a following PR. |
Codecov Report
@@ Coverage Diff @@
## master #613 +/- ##
=========================================
+ Coverage 13.6% 44.5% +30.9%
=========================================
Files 69 144 +75
Lines 3752 9542 +5790
Branches 1374 0 -1374
=========================================
+ Hits 513 4255 +3742
- Misses 2618 5287 +2669
+ Partials 621 0 -621
Continue to review full report at Codecov.
|
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.
Looks good! Thanks again!
@vitorenesduarte Awesome, thanks! Could you please create an issue and open a PR to add a changelog entry for this, mentioning said issue? |
^ This can be done as part of your follow-up PR. |
|
Before, a `query_txs` for a packet on a given chain would filter only by the packet source port, source channel and sequence. With 2 chains, there can be at most a single packet matching such filter, and this fact was assumed in the code. However, this assumption does not hold with more than 2 chains. To understand why, consider the following example with chains `ibc-0`, `ibc-1` and `ibc-2`: - a channel handshake occurs between `ibc-0` and `ibc-1`; the channel identifiers are `channel-0` on both ends - a channel handshake occurs between `ibc-1` and `ibc-2`; the channel identifier on `ibc-1` is `channel-1` and on `ibc-2` is `channel-0` If now both `ibc-0` and `ibc-2` send packets to `ibc-1` and we do a packet query filtering only by the source, such query will return packets from both `ibc-0` and `ibc-1` (as both have `channel-0` as the source channel in their packets). In this commit, we start filtering also by the destination port and destination channel. This makes the packet query unambiguous.
Closes: #614
Description
Before, a
query_txs
for a packet on a given chain would filter only by the packet source port, source channel and sequence.With 2 chains, there can be at most a single packet matching such filter, and this fact was assumed in the code.
However, this assumption does not hold with more than 2 chains. To understand why, consider the following example with chains
ibc-0
,ibc-1
andibc-2
:ibc-0
andibc-1
; the channel identifiers arechannel-0
on both endsibc-1
andibc-2
; the channel identifier onibc-1
ischannel-1
and onibc-2
ischannel-0
If now both
ibc-0
andibc-2
send packets toibc-1
and we do a packet query filtering only by the source, such query will returnpackets from both
ibc-0
andibc-1
(as both havechannel-0
as the source channel in their packets).In this commit, we start filtering also by the destination port and destination channel. This makes the packet query unambiguous.
Thanks @ancazamfir for the help debugging this issue. It was a fun one!
For contributor use:
docs/
) and code comments.Files changed
in the Github PR explorer.