When we call into another contract using SubMsg::reply_on_success, we get data fields with important info from the other contract. Especially the address on instantiate.
Let's provide some helper functions for this as it is a common task that needs a bit of knowledge of the internals.
Maybe multiple implementations - one to parse from the data field, the other from the events fields.
Events defined here See the instantiate and execute events.
You can alternately (also) extract from the data field. That is a protobuf encoded message:
InstantiateResponse
ExecuteResponse
It seems very heavy to import protobuf libs here. Best would be to manually decode this. (Write 2 functions to parse those particular protobuf formats and test them against a test suite using eg prost/protobuf as dev dependency)
There is working code for this in tgrade-valset (when it calls tg4-engagement). The point here is to make this general.
When we call into another contract using
SubMsg::reply_on_success, we get data fields with important info from the other contract. Especially the address on instantiate.Let's provide some helper functions for this as it is a common task that needs a bit of knowledge of the internals.
Maybe multiple implementations - one to parse from the data field, the other from the events fields.
Events defined here See the
instantiateandexecuteevents.You can alternately (also) extract from the data field. That is a protobuf encoded message:
InstantiateResponse
ExecuteResponse
It seems very heavy to import protobuf libs here. Best would be to manually decode this. (Write 2 functions to parse those particular protobuf formats and test them against a test suite using eg prost/protobuf as dev dependency)
There is working code for this in tgrade-valset (when it calls tg4-engagement). The point here is to make this general.