Open Hyodar opened 3 months ago
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}}"}
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.
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: