People are facing the problem that if they have a contract emitting IBC messages, it is technically impossible to test them - passing any IBC message through a router will always cause panic. It is semi-solved for staking/custom messages by a separate module for them to fail by default, but possible to overwrite their behaviour. For now, the problem exists for IBC, Stargate and Gov messages (so basically anything introduced via a
Another problem is how staking is implemented - it just enables the
stargate feature flag by default (enabling relevant features in
cosmwasm-std, but what would happen if someone would explicitly disable it - via
no-default-fetures? It would fail to compile because of a lack of staking-related types in cw-std).
This approach of the fixed module set has proven to be difficult to maintain properly. I have another idea. Let's model a module like something accepting any cosmos message and handling it optionally - if it knows how to handle it, it will return a proper result. If not - it would return some
None equivalent. If any module manages to handle the message, its processing is finished successfully.
To make it easy, I would create two generic "modules" or better "handlers".
DefaultHandler would take any message and report an "unhandled message" error. One called on the very end of a chain. The other one would be
FallbackHandler<Module, Fallback>. The
FallbackHandler tries to handle a message using
Module, and if it fails, it delegates handling it to
Fallback is typically another
DefaultHandler at the end - basically a simple linked list.
Now to make it even better API-wise,
FallbackHandler would take an even better form:
FallbackHandler<T, Filter<T>, Module<T>, Fallback>, where
Filter takes a
Cosmos message, returning some
Module<T> is a handler taking a
BankMsg) handling it. If the filter returns
Some, then only my
Module is allowed to handle the message. Otherwise, it is forwarded further (so it is shortcut-break if there is an unsupported bank message in future).
This also allows changing the handler for a particular message - as they are unique identified with
T - it would allow keeping the same Api we have now with some defaults (bank, wasmkeeper), which can be substituted with custom messages. It would also allow easily feature-enable some other implementations in future or allow others to provide custom implementation of modules not yet implemented in MT at all, under some feature flags.
Any thoughts? I am happy to provide PoC of that.