[gjermundgaraba]

Description

Follows up srdtrk's review of #1556. Packet sequences are only unique per source client, but the e2e harness identified sent packets by sequence alone and decoded SendPacket logs by hand in several places. Now every sent, acknowledged and timed-out packet is identified by source client and sequence, and one helper decodes SendPacket.

• One SendPacket decoder. e2etest.SentPackets returns the packets a router sent over a client, in log order. It replaces SendPacketSequences, sendPacketSequence, and the hand decoding in newAttestablePacket (load test) and sentPacket (deploy test).
• One send path. Transfer, GMP and IFT embed a sourceRoute and send through sourceRoute.send, which requires exactly the expected number of packets on the route's client (1, or len(requests) for IFT.SendBatch). Before, a send took the first SendPacket the router emitted on any client.
• Send results carry the emitted packet. Packet() replaces the separately tracked IFT timeout timestamp and IFTBatch.Receipt(); the attestor load test encodes the packet from it instead of re-parsing logs.
• Shared ack/timeout matching. PacketID{SourceClientID, Sequence} and three readers for WriteAcknowledgement, AckPacket and TimeoutPacket events replace the hand-written matching loops in the Transfer and GMP verifiers; the IFT *PacketIDs methods return []PacketID. The verifiers now check the packet's event is present rather than present exactly once: the router emits Noop instead of a second event for an already-handled packet.
• Route setup in one place. resolveAppRoute builds every app's route, and Deploy rejects empty, duplicate, and same-chain route IDs once instead of each app constructor checking.

Most critical to review: e2e/internal/e2etest/traffic_evm.go (SentPackets, send, the event readers) and traffic.go (PacketID, sourceRoute).

closes: FOU-1902

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work. (Linear FOU-1902, from review of test(e2e): relay an IFT transfer over a CLI-deployed Besu QBFT connection #1556)
• Include changelog entry when appropriate (e.g. chores should be omitted from changelog). (n/a: test harness only)
• Wrote unit and e2e tests if relevant. (TestSentPackets; existing e2e suites cover the rest)
• Updated documentation (docs/) if anything is changed. (n/a: no user-facing change)
• Added godoc comments if relevant.
• Self-reviewed Files changed in the GitHub PR explorer.
• Provide a conventional commit message to follow the repository standards.

🤖 Generated with Claude Code

[linear-code]

FOU-1902

[github-actions]

Vulnerable dependencies

2 advisories across 2 libraries need attention, 2 accepted.

🚨 Needs attention

github.com/cosmos/evm

In use: v0.7.3 — reached from e2e

Advisory	CVE	Fixed in	Summary
GO-2025-3684	—	no fix yet	Cosmos EVM Allows Partial Precompile State Writes in github.com/cosmos/evm

Go standard library

In use: go1.26.9 — reached from cli, e2e, gen/go/solidity-abi

Advisory	CVE	Fixed in	Summary
GO-2026-6809	CVE-2026-111943	go1.26.10	Distrust compromised intermediate certificates in crypto/x509

Run make vulncheck for the call paths. Either upgrade the library, or add the
advisory to .govulncheck-ignore with a reason if no fix exists yet.

Accepted

Listed in .govulncheck-ignore with a reason.

github.com/pion/dtls/v2

In use: v2.2.12 — reached from cli

Advisory	CVE	Fixed in	Summary
GO-2026-4479	CVE-2026-26014	no fix yet	Usage of random nonce generation with AES GCM ciphers risks leaking the authentication key in github.com/pion/dtls

golang.org/x/crypto

In use: v0.57.0 — reached from cli, e2e

Advisory	CVE	Fixed in	Summary
GO-2026-5932	—	no fix yet	The golang.org/x/crypto/openpgp package is unmaintained, unsafe by design, and has known security issues

_{From make vulncheck-json on this run: logs.}

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge; no actionable issues were found.

Summary

The e2e helpers now identify packets by source client and sequence and share one SendPacket decoder.

• The e2e harness matches each packet to its source client and sequence.
• Route setup checks that each route has a usable, unique direction.

No actionable issues were found. Runtime tests were not run.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Transfer, GMP, or IFT] --> B[sourceRoute.send]
  B --> C[Broadcast transaction]
  C --> D[SentPackets]
  D --> E[Filter router and source client]
  E --> F[Check expected packet count]
  F --> G[PacketTx and emitted packet]
  G --> H[Relay and check matching events]

Loading

_{Reviews (2) · Last reviewed commit: "test(e2e): identify packets by source cl..." · Reviewed by Greptile}

[gjermundgaraba]

@greptile review