Previous Messages Resent to L1 on Katana Restart

[ybensacq]

Describe the bug
When running Katana with the command
katana --messaging anvil.messaging.json --db-dir ./database
previously sent messages to L2 are resent to L1 upon restarting Katana.

To Reproduce
Steps to reproduce the behavior:

1. Follow all the steps in the starknet-messaging-dev repo, except start Katana with: katana --messaging anvil.messaging.json --db-dir ./database
2. Stop katana
3. Restart katana using katana --messaging anvil.messaging.json --db-dir ./database (wait for a few seconds)
4. Observe that previously sent messages are resent to L1.

Expected behavior
Messages should not be resent to L1 upon restarting Katana; the state should persist correctly between restarts.

[glihm]

@kariy would have any pointer on that one?

[StarkFishinator]

Hi, can I get assigned to this?

[glihm]

This seemed to be caused by the messaging service not having context of where to start the message processing.

dojo/crates/katana/core/src/service/messaging/service.rs

Lines 65 to 69 in 30e9803

	messenger,
	gather_from_block,
	send_from_block: 0,
	msg_gather_fut: None,
	msg_send_fut: None,

For gathering the messages from the L1, we have an item in the configuration that may be used for that. However, as we're using a database, this block number may be different if Katana stops without graceful shutdown.

Currently, on the providers traits we have, there's no trait to store messaging information (last block gathered, last block sent messages). @kariy does it sound reasonable to add a provider trait to store such information and allow Katana to restart from an existing database being aware of which blocks must be processed for L1 <> L2 messaging?

@StarkFishinator are you feeling confident to dive into that? Or do you have an other strategy to propose?

[glihm]

@ybensacq we've synced with @kariy and here's the way we could solve that:

1. Katana has a genesis configuration and this is where we want the initial configuration for the L1 block to start fetching messages:

   dojo/crates/katana/primitives/src/genesis/mod.rs

   Line 85 in 4f76fd7

   pub struct Genesis {

2. Then, Katana should keep into the database some pointer on the block/transaction/event (we should evaluate the better) from where the message is actually fetched. To ensure correct restart when a database is used. We could have a new provider trait to handle those pointers.
3. In the case of appchain->base_layer messages, we don't think it's necessary to have them into the genesis or messaging configuration. As when Katana is started with a database, the pointer will be enough to resume the operation.