fix: initialize involved accounts addresses to empty slice instead of nil

[dadamu]

Description

Currently, our messages table has a field called involved_accounts_addresses which is parsed from tx.events and it does not allow NULL value. However, it might be a nil slice when a transaction does not include the event related to addresses, so error messages could happen:

ERR error while handling message err="pq: null value in column \"involved_accounts_addresses\" of relation \"message_68\" violates not-null constraint" height=6808106 module=messages msg_type=/canine_chain.storage.MsgRequestReportForm tx_hash=0F587A0BE501C2DFCA092A5640D3652179567FECFEBE4B98340FA6BB4D3F25DA

References:
https://bigdipper.live/jackal/transactions/0F587A0BE501C2DFCA092A5640D3652179567FECFEBE4B98340FA6BB4D3F25DA

Checklist

• Targeted PR against correct branch.
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Wrote unit tests.
• Re-reviewed Files changed in the Github PR explorer.

[0x7u]

💯

[MonikaCat]

@dadamu Hey actually we shouldn't store an empty value for involved_accounts_addresses, there should be at least one address for every message, in this case we should be able to store at least the creator address jkl1uh6xqncwajvcfyzvxs0gzu363apfk4tdset8d0, so I think we should test and fix the message handler instead.

[dadamu]

@MonikaCat The creator field can be known only if we register /canine_chain.storage.MsgRequestReportForm into Codec. As we are going to get rid of Codec register issue, we can only parse the address from events.

The empty involved accounts addresses is happening since Jackal is using Cosmos-SDK v0.45.x version, it would be at least signer event and solve the issue when they upgrade to ^0.46.x, reference here.

As a result, I would consider this is the Jackal chain bug that doesn't register a proper event attribute to include at least signer address for the messages. There is even no way to get the transactions by address with the query message.signer = 'jkl1uh6xqncwajvcfyzvxs0gzu363apfk4tdset8d0' by using CometBFT tx search endpoint.

In order to include the chain who do not emit events properly, I think it would be better to allow involve account addresses to an empty array. What do you think?

[MonikaCat]

@dadamu right I see, but in this case we will not be able to query and display those txs in account page - it's going to look like some txs are missing, how about we keep parsing the msgs using the codec just for jackal until they upgrade to cosmos-sdk v0.46.x ? What do you think about it?

[dadamu]

@MonikaCat It is fine that we cannot link those txs to account. Currently on Jackal no one can get transactions by given account address because they didn't set event properly. If we keep codec to parse messages, we need to maintain several versions for Juno and Callisto, I don't think it is worth to remain Codec because it is wasting our resource.

[MonikaCat]

utACK