Investigate delay for current blocks MQ consumption

[Hyodar]

When the operator initializes, it sends out some messages without NEAR DA data for a while. It could make sense that if the indexer has been running for a while, the MQ will already have quite a few messages, so it takes a bit for it to get to the current ones. We do have expiration set up #148, but it's most likely not working properly. The approach here would be:

• Use the docker compose environment without the operator to check if Set message TTL in indexer publisher #148 is working or not, then turn on the operator after some minutes to check how long it takes for it to emit a message with the NEAR DA commitment
• If it is not considerably delayed, then we should investigate what is the actual reason for that
• If it is, then we need to e.g. empty MQ when starting the operator

[mikhailUshakoff]

#148 is working well. When the operator initializes, it takes around 30 seconds to reach the current message, and it does not send any messages without NEAR DA data during this process.

However, if the relayer or RabbitMQ is not running, the operator starts sending messages without NEAR DA data.

INFO    attestor/attestor.go:224        Processing header       {"rollupId": 2, "height": 27}
INFO    attestor/attestor.go:261        MQ timeout      {"rollupId": 2, "height": 21}
INFO    operator/rpc_client.go:357      Sending signed state root update message to aggregator  {"signedStateRootUpdateMessage": "&messages.SignedStateRootUpdateMessage{Message:messages.StateRootUpdateMessage{RollupId:0x2, BlockHeight:0x15, Timestamp:0x6683c868, NearDaTransactionId:[32]uint8{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, NearDaCommitment:[32]uint8{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, StateRoot:[32]uint8{0xd3, 0xf, 0x1a, 0xca, 0x31, 0x8d, 0x34, 0xad, 0x90, 0x31, 0x59, 0x6, 0x6b, 0xb5, 0xb9, 0x90, 0x73, 0x8, 0xbe, 0xc4, 0x40, 0x65, 0x64, 0x58, 0x25, 0xf7, 0x12, 0x9a, 0x96, 0xc0, 0x5f, 0x6f}}, BlsSignature:bls.Signature{G1Point:(*bls.G1Point)(0xc000284278)}, OperatorId:types.Bytes32{0x66, 0x16, 0x38, 0xfc, 0xbd, 0xe3, 0xeb, 0xaa, 0x8, 0x4a, 0x6a, 0x24, 0xf8, 0xa7, 0x8a, 0x5, 0x67, 0x2a, 0x40, 0x55, 0x8b, 0x76, 0xf2, 0xf2, 0xd, 0xf2, 0xd, 0xe4, 0x6, 0x17, 0x75, 0xec}}"}

[Hyodar]

It seems very likely to me this is actually an initialization order issue on the operator setup. When the operator runs docker compose up, the expected behavior is the operator node itself will only initialize once the indexer is fully synced. However, once I did notice the indexer healthcheck was true before actually being synced. Only happened once, but this lines up with getting no NEAR DA data in the end.