Analyze if removing a consumer chain on IBC timeout is not too severe

[tbruyelle]

vaas/x/vaas/provider/keeper/relay.go

Lines 37 to 48 in e7a3153

	func (k Keeper) OnTimeoutPacketV2(ctx sdk.Context, sourceClientID string) error {
	consumerId, found := k.GetClientIdToConsumerId(ctx, sourceClientID)
	if !found {
	k.Logger(ctx).Error("packet timeout, unknown client:", "clientID", sourceClientID)
	return errorsmod.Wrapf(
	providertypes.ErrInvalidConsumerClient,
	"timeout on unknown client %s", sourceClientID,
	)
	}
	k.Logger(ctx).Info("packet timeout, deleting the consumer:", "consumerId", consumerId, "clientId", sourceClientID)
	return k.StopAndPrepareForConsumerRemoval(ctx, consumerId)
	}

When the provider chain receives a packet timeout, it stops and removes the related consumer chain.

Given that a packet timeout can happen if the consumer chain is just not responsive (or just the RPC targeted by the relayer, if there's a single one), I wonder if this is not too severe.

Summoning @clockworkgr since it's related to relayer behavior.

[clockworkgr]

It depends what the timeoutTimestamp/timeoutHeight for the packet is. Whether it's severe or not largely depends on that. If the packets generated by the provider have a long enough timeout to allow for flaky connections/relays then no

[tbruyelle]

@clockworkgr Makes sense yes I agree.

Does the relayer have a retry mechanism for the RecvPacket in case of the first attempt fails ?
Does he handle a list of different RPCs in case one of them is down ?

[clockworkgr]

@clockworkgr Makes sense yes I agree.

Does the relayer have a retry mechanism for the RecvPacket in case of the first attempt fails ?
Does he handle a list of different RPCs in case one of them is down ?

Each polling cycle queries unreceived packets so yeah it retries by default.

Only uses single RPCs though

[tbruyelle]

Only uses single RPCs though

is it the case for hermes for example ? We know how dangerous it can be to rely on a single RPC, it can be poisonned.