Use []abci.Event instead of sdk.Events in argument to testing pkg event parsing functions

[colin-axner]

Summary

Change functions in testing/event.go to use []abci.Event instead of sdk.Events

Problem Definition

In v0.47 SDK, SendMsgs() will end up calling SimDeliver which has access to sdk.Result which has sdk.Events because of this conversion

In v0.50, begin block, deliver tx, and end block are combined into FinalizeBlock which returns a ResponseFinalizeBlock which contains []abci.ExecTxResult. These tx results will contain []abci.Event instead of sdk.Events

Instead of converting []abci.Event into sdk.Events, we should pass around []abci.Event (SendMsgs will also be updated to return a abci.ExecTxResult instead of sdk.Result (but this will occur with the SDK bump)

Proposal

Change functions in testing/event.go to use []abci.Event instead of sdk.Events

Thanks @alpe for the reference fix

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[DimitrisJim]

Just for clarity, this is not in any way affected if we moved to typed events, correct? Typed or not typed, we'll still be getting an array of abci.Event from SendMsgs.

[colin-axner]

I think that's correct. By typed events you mean creating a type per event type. For example:

type CreateClientEvent struct {}

?

In this situation, indeed FinalizeBlock will still return us a abci.Event as the typed event would only be typed until we emit it. There was discussion a couple years ago to add typed events to the SDK, but it was partially implemented and I'm not sure if it is used today.

[DimitrisJim]

ah, typed events in the way the SDK defined them was what I was referring to. Missing the fact that they aren't really used, there's an old issue you opened on this which might need to be re-examined #54 (and possibly closed)

[colin-axner]

Yes exactly. I think #54 should likely be closed as I haven't seen a reason to implement it