Identify the packet blocking an ordered IBC channel
An ordered channel advances its receive sequence one packet at a time. A relayer that has packet 17 ready may first need the packet at position 16.
Read the receiver’s expected sequence
Use a TLS gRPC destination in DST and replace the example port and channel. Confirm the channel ordering is ORDERED, then inspect nextSequenceReceive and the query height.
grpcurl -d '{"portId":"example","channelId":"channel-3"}' "$DST" ibc.core.channel.v1.Query/NextSequenceReceive
If the counter is 16 and the queue contains 17 and 18, investigate the source commitment and packet data for 16. Sending later packets first does not close the gap on a strictly ordered channel.
Recheck channel state after a timeout
Inspect whether the channel remains open before retrying. IBC Classic ordered channels can close on timeout. Unordered channels track receipt individually and require a different diagnostic; this counter cannot identify every missing unordered packet. github.com ibc-go Query API