Emit events from x/gov proposal messages execution

[migueldingli1997]

Summary of Bug

When a proposal in x/gov has passed, the EndBlocker gets all the proposal messages and executes them one by one. I would have expected that the events emitted by these messages get included in that particular block's end-block events. This expectation seems to be justified by the event emission that comes after the message execution.

However I noticed that the handler creates a new event manager, overriding but not overwriting the one already in ctx. So when the event manager is accessed after message execution, it no longer has any of the emitted events. Instead, these events are actually in the result returned by the handler, which get assigned here. Unfortunately this result returned by the handler is ignored and so the events are never emitted.

I think events should instead be emitted by aggregating all events generated by messages into a list of events, and then emitting the events in that list, similar to what is done in normal message handling.

Version

v0.46.1

Steps to Reproduce

• Execute a governance proposal with at least one message that emits its own events
• Query the block results of the block at which the proposal passes
• The block results will not include the events emitted by the message

[damiannolan]

We experienced this issue when attempting to write an e2e integration test with interchain accounts and x/gov, but the issue would be the same for any x/gov executed ibc message as relayers rely on events for packet processing.

I noticed that #13063 has been implemented but not included into the release/v0.46.x branch. I didn't test out this fix as there was a large number of breaking changes when trying to point my go.mod to the sdk tip of main.

I did test out a simple replace to a local checkout and not discarding the sdk.Result returned from the handler, and emitting the events propagated through that. This worked and hermes could act on events to relay ibc packets.

Could we see #13063 backported and included in a v0.46 point release?
Or would you accept a PR to release/v0.46x for not discarding the sdk.Result like I mentioned above?

Thanks ❤️

[damiannolan]

The same behaviour still exists in v0.46.4.
It's entirely down to the fact that a new EventManager is created when handler() is invoked by x/gov or anywhere else that uses msg routing, and therefore any of the events emitted are lost and swallowed into the void, because writeCache() is expected to be invoked by the caller.