Unable to parse ws log into MessageState

[bd21]

Raw logs:

│ 3:17AM INF Filtered tx 0xafb2c9ec964382c8d59eeb3fec9e357bbfdf2bd9040f4ba63f20c52b2e6d8093 because relaying from 0 to 1 is not enabled │
│ 3:47AM INF New stream msg from 0 with tx hash 0xbd755df247bbf656321e6a3405935946af063fe2d2404d576d560c347487923c │
│ 3:47AM INF Filtered tx 0xbd755df247bbf656321e6a3405935946af063fe2d2404d576d560c347487923c because relaying from 0 to 1 is not enabled │
│ 4:35AM INF New stream msg from 0 with tx hash 0x7db7f51ce58d57081cbaec8339bb8fa17b26c75733d79cf0b5f229b058eee30e │
│ 4:35AM INF Filtered tx 0x7db7f51ce58d57081cbaec8339bb8fa17b26c75733d79cf0b5f229b058eee30e because relaying from 0 to 1 is not enabled │
│ 4:44AM INF New stream msg from 0 with tx hash 0xd5e91d25a5c2c1b63c7414ede02095b6927e1bb5ce102cb0f89ed90f6b8b3322 │
│ 4:44AM ERR Unable to parse ws log into MessageState, skipping │
│ 4:44AM INF Filtered tx 0xd5e91d25a5c2c1b63c7414ede02095b6927e1bb5ce102cb0f89ed90f6b8b3322 because relaying from 0 to 1 is not enabled │
│ 6:46AM INF New stream msg from 0 with tx hash 0x48a60918ebe397

• Reproduce bug with the given txn hashes
• determine root cause
• push fix + test

[jtieri]

Desc

Similar errors are encountered and logged when dealing with historical txs and their associated logs.

�[90m4:26PM�[0m �[1m�[31mERR�[0m�[0m Unable to parse history log into MessageState, skipping �[36merr=�[0m"unable to parse txn into message.  tx hash 0xafb2c9ec964382c8d59eeb3fec9e357bbfdf2bd9040f4ba63f20c52b2e6d8093"

Essentially EvmLogToMessageState tries to parse the Message.MessageBody, which is a []byte, into either a BurnMessage or a MetadataMessage and when it is not successful an error is returned.

Sometimes we see unsupported messge types come in.

Example:

https://goerli.etherscan.io/tx/0x07dd8e6ab671165b1519a5111ee374960c0be294703c1ac879e26fc08c293158

The method SendMessage is called which appears to return

event MessageReceived(
        address indexed caller,
        uint32 sourceDomain,
        uint64 indexed nonce,
        bytes32 sender,
        bytes messageBody
    );

which does not seem to correlate to the BurnMessage or MetadataMessage types that we are explicitly handling.

If we only care about BurnMessage and MetadataMessage I think we just need to have more robust error handling that provides more succinct logs to indicate what message type is attempting to be handled and why the parsing of the MessageBody fails.

Notes

I have not been able to reproduce the error with the web socket stream, only with historical messages.

[jonathanpberger]

@jtieri added better error handling in #18

Closing ticket.