We use json serde on CallMessage to support sov-cli parsing. The current path we follow is
-> user supplies json that matches the CallMessage
-> cli_parser attribute macro is used to annotate runtime and provides a function that can deserialize from JSON to a value of the CallMessage enum for that module
-> cli_parser attribute macro also serializes the CallMessage into Borsh to prep the transaction for submission to DA layer
The problem is in step 2. we derive Serialize and Deserialize for each CallMessage in our runtime that we want to support, but adding it as a bound for the CallMessage associated type of the module has some ripple effects where it requires even Context to have the serde bounds.
This is fixable, but creating this issue to track instead of doing it as part of the cli parser since its a bit more involved
I guess this problem is kind of leftover from situation where we had borsh and serde mixed. Since we are on track to have it solved, this issue aligns with what needs to be done.
We use json serde on CallMessage to support sov-cli parsing. The current path we follow is -> user supplies json that matches the CallMessage -> cli_parser attribute macro is used to annotate runtime and provides a function that can deserialize from JSON to a value of the CallMessage enum for that module -> cli_parser attribute macro also serializes the CallMessage into Borsh to prep the transaction for submission to DA layer
The problem is in step 2. we derive Serialize and Deserialize for each CallMessage in our runtime that we want to support, but adding it as a bound for the CallMessage associated type of the module has some ripple effects where it requires even Context to have the serde bounds.
This is fixable, but creating this issue to track instead of doing it as part of the cli parser since its a bit more involved