Duplicate events in tx_responses

[GMaiolo]

Describe the Bug
For example, for /cosmos/tx/v1beta1/txs?events=tx.height=4731308
The following event appears repeated twice

{
  "type": "zetachain.zetacore.crosschain.EventZrcWithdrawCreated",
  "attributes": [
    {
      "key": "amount",
      "value": "\"\"",
      "index": true
    },
    {
      "key": "cctx_index",
      "value": "\"0x749d4b07790f3d6f9f474d71f10431dd00c080cad80ce10cf03511310356e2d2\"",
      "index": true
    },
    {
      "key": "inbound_hash",
      "value": "\"0xde276fa6700730a772f9294360227c3d9e9700a5ab4203ca0c0d9b8d90cb3843\"",
      "index": true
    },
    {
      "key": "msg_type_url",
      "value": "\"/zetachain.zetacore.crosschain.internal.ZRCWithdrawCreated\"",
      "index": true
    },
    {
      "key": "new_status",
      "value": "\"PendingOutbound\"",
      "index": true
    },
    {
      "key": "receiver",
      "value": "\"\"",
      "index": true
    },
    {
      "key": "receiver_chain",
      "value": "\"\"",
      "index": true
    },
    {
      "key": "sender",
      "value": "\"0xD494685B830e8C81Af6c7DA2B6E6C70e526019cE\"",
      "index": true
    },
    {
      "key": "sender_chain",
      "value": "\"\"",
      "index": true
    }
  ]
}

To Reproduce
Check tx_responses in /cosmos/tx/v1beta1/txs?events=tx.height=4731308

Expected Behavior
Only one event appears

[CharlieMc0]

I think this was solved, right @lumtis?

The fix should be deployed in testne and mainnet now @GMaiolo

[GMaiolo]

I think this was solved, right @lumtis?

The fix should be deployed in testne and mainnet now @GMaiolo

I still see it duplicate in our internal RPC, does it require action in nodes to fix?

[lumtis]

Yes, I had a fix related to duplicated events but it seems it was a different issue.

@GMaiolo are the two duplicated events exactly the same in their structure? Is it happening on mainnet?

This event has always been emitted, this could be a change brought from the v47 upgrade

[skosito]

i think we can close this one as it was fixed with #2836

it is verified locally and it seems that issue doesn't appear on live networks after v19.1.6 release when fix was deployed, as expected

we can reopen if we see it again