A way to dynamically (programmatically) suspend and resume inbound XCM channels at bridge hub

[svyatonik]

This idea was born here: #2213 (comment)

TLDR: we want the chain that "owns" the bridge endpoint to respect bridge limits and rules. Those limits and rules shall guarantee that this chain uses some kind of rate limiter + there is a running relayer for the dedicated messages lane. When we see that the "owner" violates those rules, we have following options (at the bridge hub):

1. simply start dropping all inbound XCM messages until owner fixes the issue. This is not good, because messages may have bundled assets and those assets will be lost;
2. stop processing inbound XCM messages until owner fixes the issue.

Bridges collective mind has selected the 2nd option. There are couple of options on how to implement that:

1. (this option is assumed by the current implementation of XCM bridge hub pallet (will be deployed at bridge hubs) #2213) add a way to exclude channel from the "service" procedure. For example current cumulus-pallet-xcmp-queue has the service_xcmp_queue where we can check if the channel is artificially suspended by the bridge (or someone else) and simply stop processing messages. XCM queues have the "suspend" signal that will be sent to the "owner" chain soon after we stop handling inbound messages (when there are more than limit messages in the queue). After this signal is received, the messages will start piling up at the "owner" chain outbound queue instead, which is ideal for us;
2. suggested by @bkontur here: XCM bridge hub pallet (will be deployed at bridge hubs) #2213 (comment). It is to physically close the channel, potentially using XCM instructions (unimplemented). If we'll choose this way, we'll need to adjust current implementation of XCM bridge hub pallet (will be deployed at bridge hubs) #2213 (see "TODOs" referencing this issue in the code).

[svyatonik]

paritytech/substrate#14318

[svyatonik]

I think we've decided NOT to pause XCM channels, because e.g. channel between at Polkadot/Kusama AH and BH is used by two bridges already. And if one bridge is lagging, we shall not halt the other bridge. So the proper way is the #2406

[bkontur]

So the proper way is the #2406

2406 is this closed issue, did you mean some other issue?

[svyatonik]

So the proper way is the #2406

2406 is this closed issue, did you mean some other issue?

It was paritytech/polkadot-sdk#5062, sorry :)