apollo_l1_provider: check for uninitialized instead of bootstrapping+sync started

[guy-starkware]

No description provided.

[reviewable-StarkWare]

This change is 

[guy-starkware]

• apollo_l1_provider: replace bootstrapping with catching up #10726
• apollo_l1_provider: rename catch_up_height and historic height #10725
• apollo_l1_provider: scraper historic height is one more #10724
• apollo_l1_provider: minor updates to some bootstrapping tests of the L1 provider #10702
• apollo_l1_provider: add reset_bootstrapper function #10513
• apollo_l1_provider: check for uninitialized instead of bootstrapping+sync started #10512 👈 (View in Graphite)
• apollo_l1_provider: add verification that tx is pending when getting it from proposable index #10511
• apollo_l1_provider: improve add_tx and prevent double scraping #10508
• apollo_l1_provider: add l1_block_time as a config parameter #10505
• apollo_l1_provider: change L1_BLOCK_TIME to be 12 seconds #10544
• apollo_l1_provider: fix log message when skipping over historic heights #10465
• apollo_l1_provider: reduce number of provider error variants #10414
• apollo_l1_provider: remove some panics in the L1 Provider #10411
• main-v0.14.1

This stack of pull requests is managed by Graphite. Learn more about stacking.

[sirandreww-starkware]

Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on @guy-starkware)

---

crates/apollo_l1_provider/src/test_utils.rs line 104 at r1 (raw file):

            tx_manager: content.tx_manager_content.map(Into::into).unwrap_or_default(),
            // The real Provider starts as Uninitialized by default, but for testing purposes we
            // start it as Pending.

Should we do this? can't we follow a similar flow to make it pending?

[guy-starkware]

Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on @sirandreww-starkware)

---

crates/apollo_l1_provider/src/test_utils.rs line 104 at r1 (raw file):

Previously, sirandreww-starkware (Andrew Luka) wrote…

Should we do this? can't we follow a similar flow to make it pending?

There are three options:

1. Make it Pending by default, which is what most tests expect (those that aren't about initialization). Requires least changes in existing tests.
2. Make it Uninitialized by default, then add with_state to all the tests that need it to already be in Pending.
3. Make it Uninitialized and add code to make it bootstrap to get into Pending mode (the "more realistic flow"). That would add some complexity to most of the tests.

Looking at these three options, I prefer (1). But I'm open to other ideas or if you have some other reasons we should pick (2) or (3).

[sirandreww-starkware]

Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on @guy-starkware)

---

crates/apollo_l1_provider/src/test_utils.rs line 104 at r1 (raw file):

Previously, guy-starkware wrote…

There are three options:

1. Make it Pending by default, which is what most tests expect (those that aren't about initialization). Requires least changes in existing tests.
2. Make it Uninitialized by default, then add with_state to all the tests that need it to already be in Pending.
3. Make it Uninitialized and add code to make it bootstrap to get into Pending mode (the "more realistic flow"). That would add some complexity to most of the tests.

Looking at these three options, I prefer (1). But I'm open to other ideas or if you have some other reasons we should pick (2) or (3).

Can we add a test for 3 and assert that the object is identical to the object used by most of the other test?
That way we can be sure that we're testing a state that we would actually get in production

[guy-starkware]

Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on @sirandreww-starkware)

---

crates/apollo_l1_provider/src/test_utils.rs line 104 at r1 (raw file):

Previously, sirandreww-starkware (Andrew Luka) wrote…

Can we add a test for 3 and assert that the object is identical to the object used by most of the other test?
That way we can be sure that we're testing a state that we would actually get in production

It is actually really hard to get the provider to be identical to one that has undergone the full process of bootstrapping.
I'll try to do something like that in a different PR but it needs more thought.

[guy-starkware]

Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on @sirandreww-starkware)

---

crates/apollo_l1_provider/src/test_utils.rs line 104 at r1 (raw file):

Previously, guy-starkware wrote…

It is actually really hard to get the provider to be identical to one that has undergone the full process of bootstrapping.
I'll try to do something like that in a different PR but it needs more thought.

Ok, so for the trivial case of having no txs and no need for bootstrapping (e.g., we get initialized directly into the correct block height) then the test is very easy to write. I added it in this PR.

[sirandreww-starkware]

Reviewable status: 0 of 4 files reviewed, all discussions resolved (waiting on @ShahakShama)

[ShahakShama]

@ShahakShama reviewed 3 of 4 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @guy-starkware)

[guy-starkware]

@guy-starkware reviewed 1 of 4 files at r1, 3 of 3 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @guy-starkware)