@kariy would have any pointer on that one?

Hi, can I get assigned to this?

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

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?

@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.