experimental: advance-runner does not close epochs when claims stream has events from a different dapp address

[endersonmaia]

🙂 Expected behavior

When using rollups-node with CARTESI_EXPERIMENTAL_SUNODO_VALIDATOR_ENABLED = 'true' and defining CARTESI_EXPERIMENTAL_SUNODO_VALIDATOR_REDIS_ENDPOINT so that you can run the cartesi-rollups-authority-claimer outside the supervision of the rollups-node go supervisor pointing to the same redis isntance..

It's expected that one can start another rollups-node instance for another application with the same setup.

At the end, multiple rollups-node will feed the {chain-XXX}:rollups-claims and a single claimer configured to make claims for that XXX chain should be able to make all that claims.

🫠 Actual behavior

In the setup described above, the advance-runner for a specific rollups-node application instance can't append the stream if there's already some entries for another application.

🧪 Minimal test case

I don't have an automated test, but have evidence from the logs and some dumps from redis.

The following dump, is from the rollups-claimer stream with a previous version of the bug-buster application.

When the stream had this content, the new version of the bug-buster (another contract address), the advance-runner logged the message produced claim but the stream never was appended with the claim.

XRANGE "{chain-11155420}:rollups-claims" - +
1) 1) "1719522678183-0"
   2) 1) "payload"
      2) "{\"dapp_address\":\"548fce869928a92f82a1f3fa1e6a918d44d8abdc\",\"epoch_index\":0,\"epoch_hash\":\"b8e1f606fa583b58dde40dd2fc557876621f801746108ecee3253766439f9beb\",\"first_index\":0,\"last_index\":9}"
2) 1) "1719522684214-0"
   2) 1) "payload"
      2) "{\"dapp_address\":\"548fce869928a92f82a1f3fa1e6a918d44d8abdc\",\"epoch_index\":1,\"epoch_hash\":\"dde3a812ed12891d0bd906b3005b2955969b38f9b497dd29c9631243f006b09a\",\"first_index\":10,\"last_index\":15}"
3) 1) "1719522690236-0"
   2) 1) "payload"
      2) "{\"dapp_address\":\"548fce869928a92f82a1f3fa1e6a918d44d8abdc\",\"epoch_index\":2,\"epoch_hash\":\"96a7e989fd4cf739f9334945883ef9e5ec89dd280b49426081a590cd134792e6\",\"first_index\":16,\"last_index\":18}"
4) 1) "1719522694257-0"
   2) 1) "payload"
      2) "{\"dapp_address\":\"548fce869928a92f82a1f3fa1e6a918d44d8abdc\",\"epoch_index\":3,\"epoch_hash\":\"e75419bf3ef5a098fc57c3a4143393943a738e9d56a1488f425ee02aeb88b68d\",\"first_index\":19,\"last_index\":21}"

After deleting the stream, advance-runner was able to create the stream and finally produce the claim entries into the rollups-claims stream.

🌎 Environment

This was observed with rollups-node:v1.5.0-rc1.

✔️ Possible solutions

A

We could work with a stream for each $chain-$dapp pair, as we do with inputs and outputs streams.

That would probably involve multiple components, like advance-runner and authority-claimer, at least.

• {chain-xxx-app-yyy}:rollups-inputs
• {chain-xxx-app-yyy}:rollups-outptus
• {chain-xxx-app-yyy}:rollups-claims

B

We could make advance-runner aware of multiple applications when appending thev stream.

Probably, this would need to change only advance-runner internal logic.

A Redis Stream, is an append only data structure, and it would be necessary to navigate all the stream elements to know if we should add a claim entry or not.

Maybe we could leverage Consumer Groups, but I'm not sure if that's possible, and we'd need to investigate.

References:

• https://redis.io/docs/latest/develop/data-types/streams/
• https://redis.io/docs/latest/develop/data-types/streams/#consumer-groups