bridge-hub-router should not throw xcm DestinationUnsupported error

[yrong]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

bridge-hub-router pallet should not throw DestinationUnsupported error when it can't process the message to Ethereum, context and more details in Snowfork#140

Steps to reproduce

No response

[yrong]

Context

Snowfork#140 (comment)

[bkontur]

Thank you for finding this. DestinationUnsupported is ok for this case, but the validation is on the wrong place :), I prepared fix here: #4162 but I want to add more tests tomorrow before merging.

Everywhere the checking version or wrap_version for destination is performed, we use DestinationUnsupported, which means:

        /// The given message cannot be translated into a format that the destination can be expected
	/// to interpret.
	DestinationUnsupported,

which is exactly the case here. E.g:
XcmpQueue - https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/pallets/xcmp-queue/src/lib.rs#L917-L918
ParentAsUmp - https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/primitives/utility/src/lib.rs#L71
ChildParachainRouter - https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/runtime/common/src/xcm_sender.rs#L122

And if you check all those implementations, everywhere there is a check for reachable location, if router cannot reach the particular destination or location pattern, then it returns NotApplicable and gives opportunity to the other routers in tuple.

        /// The message and destination combination was not recognized as being reachable.
	///
	/// This is not considered fatal: if there are alternative transport routes available, then
	/// they may be attempted.
	NotApplicable,

So the bridge-hub-router is designed exactly to be aligned with the other routers.

[yrong]

Cool! Thanks for confirming that.