Don't relay packets from other clients/connections

[webmaster128]

In the following logs you see that

1. Client 07-tendermint-16 is on nois-testnet-005 updated
2. A packet from channel channel-175 (client 07-tendermint-15) is relayed
3. A packet from channel channel-198 (client 07-tendermint-16) is relayed

But 07-tendermint-15 was not updated by this instance (and should not because this is a different client). Since 2. and 3. are in the same transaction, both packets fail to be received.

As far as I can tell the issue here is that a connection is configured but then the packet search does not filter by connection.

---

info: Update Client on nois-testnet-005
verbose: Client state height before update: {6 1550903}
verbose: [uni-6] Get latest commit
verbose: [uni-6] Get validator set for height 1550914
verbose: [uni-6] Get header for height 1550914
verbose: [uni-6] Get validator set for height 1550904
verbose: [uni-6] Get header for height 1550904
verbose: [nois-testnet-005] Update Tendermint client 07-tendermint-16 to: trustedHeight={6 1550903} signed header height=1550914
verbose: Client state height after update: {6 1550914}
verbose: Creating proofs with height: {6 1550914}
verbose: [nois-testnet-005] Receive 2 packets..
verbose: [nois-testnet-005] Sending packet #10510 from nois-testnet-005:channel-175 {"amount":"50000000","denom":"transfer/channel-175/unois","receiver":"nois1xgnpkzr86cl7d2mjwdhalyt9md3vyfk5d66r9j4lfvsgkjc6wthse2q53d","sender":"juno1pjpntyvkxeuxd709jlupuea3xzxlzsfq574kqefv77fr2kcg4mcqvwqedq"}
verbose: [nois-testnet-005] Sending packet #9056 from nois-testnet-005:channel-198 {"request_beacon":{"after":"1684707607074764114","origin":"eyJzZW5kZXIiOiJqdW5vMTRldXQ4NXYyM3MweWtlY241c3RsZGN4ZW4wZnNjbTJhdTdhOTVrM2RjOHM0cWs3MmprNnE0NHdybHYiLCJqb2JfaWQiOiJQaW5nIDAuODk4NTAwMTA2MjQyODM1In0="}}
error: Caught error: Broadcasting transaction failed with code 7 (codespace: client). Log: receive packet verification failed: couldn't verify counterparty packet commitment: failed packet commitment verification for client (07-tendermint-15): please ensure the proof was constructed against a height that exists on the client: consensus state does not exist for height 6-1550914: consensus state not found {"code":7,"codespace":"client","log":"receive packet verification failed: couldn't verify counterparty packet commitment: failed packet commitment verification for client (07-tendermint-15): please ensure the proof was constructed against a height that exists on the client: consensus state does not exist for height 6-1550914: consensus state not found"}

[ethanfrey]

Here is the relevant code where we determine the packets to get: https://github.com/confio/ts-relayer/blob/main/src/lib/link.ts#L576-L582

Which calls into querySentPackets https://github.com/confio/ts-relayer/blob/main/src/lib/endpoint.ts#L121-L124

Both final queries to get the packets (from tx and from block events), include the connection id:

https://github.com/confio/ts-relayer/blob/main/src/lib/endpoint.ts#L73-L79 and https://github.com/confio/ts-relayer/blob/main/src/lib/endpoint.ts#L101-L107

No obvious cause.
I do think I assumed only one connection per client, so if that doesn't hold true the code may have bugs mapping them

[webmaster128]

I'm pretty sure this is what happens: A transaction that contains a packet for the right connection is found via the tx search linked above. However, that transaction then also contains packets for other connections. Since there is no packet level filtering implemented, all packets are relayed.

[ethanfrey]

Ah, interesting observation