apollo_l1_provider: add reset_bootstrapper function

[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 👈 (View in Graphite)
• apollo_l1_provider: check for uninitialized instead of bootstrapping+sync started #10512
• 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 1 files reviewed, 1 unresolved discussion (waiting on @guy-starkware)

---

crates/apollo_l1_provider/src/l1_provider.rs line 447 at r1 (raw file):

            self.state = ProviderState::Pending;
            self.reset_bootstrapper();

This is so next time you try to bootstrap you start from a reset bootstrapped? Is it not better to reset once the state moves to bootstrapping?

[guy-starkware]

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

---

crates/apollo_l1_provider/src/l1_provider.rs line 447 at r1 (raw file):

Previously, sirandreww-starkware (Andrew Luka) wrote…

This is so next time you try to bootstrap you start from a reset bootstrapped? Is it not better to reset once the state moves to bootstrapping?

It would make life a little bit harder for testing, since you'd be initializing the test with some particular bootstrapper, and then have to somehow skip the part where you reset it just before starting bootstrapping.

[sirandreww-starkware]

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

---

crates/apollo_l1_provider/src/l1_provider.rs line 447 at r1 (raw file):

Previously, guy-starkware wrote…

It would make life a little bit harder for testing, since you'd be initializing the test with some particular bootstrapper, and then have to somehow skip the part where you reset it just before starting bootstrapping.

Can we add a test that would test this flow at least?

[sirandreww-starkware]

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

---

crates/apollo_l1_provider/src/l1_provider.rs line 447 at r1 (raw file):

Previously, sirandreww-starkware (Andrew Luka) wrote…

Can we add a test that would test this flow at least?

Wait what am I talking about, wrong PR...

[sirandreww-starkware]

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

---

crates/apollo_l1_provider/src/l1_provider.rs line 447 at r1 (raw file):

Previously, sirandreww-starkware (Andrew Luka) wrote…

Wait what am I talking about, wrong PR...

Doesn't reset_bootstrapper return the bootstrapper to a state where it can begin bootstrapping (identical to the initial bootstrapper) Why would you need to avoid resetting it in tests?

[guy-starkware]

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

---

crates/apollo_l1_provider/src/l1_provider.rs line 447 at r1 (raw file):

Previously, sirandreww-starkware (Andrew Luka) wrote…

Doesn't reset_bootstrapper return the bootstrapper to a state where it can begin bootstrapping (identical to the initial bootstrapper) Why would you need to avoid resetting it in tests?

Yeah, I guess if we are going to override the bootstrapper state in the test we can also circumvent the "reset" part, too.

[guy-starkware]

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

---

crates/apollo_l1_provider/src/l1_provider.rs line 447 at r1 (raw file):

Previously, guy-starkware wrote…

Yeah, I guess if we are going to override the bootstrapper state in the test we can also circumvent the "reset" part, too.

I had to change only one test to skip the "normal" way we trigger bootstrapping, but that's not too bad.

[sirandreww-starkware]

Reviewable status: 0 of 2 files reviewed, 2 unresolved discussions (waiting on @guy-starkware and @ShahakShama)

---

crates/apollo_l1_provider/src/l1_provider.rs line 335 at r2 (raw file):

        self.reset_bootstrapper();
        self.state = ProviderState::Bootstrap;
        self.bootstrapper.start_l2_sync(self.current_height, target_height);

make this a function

Code quote:

        self.state = ProviderState::Bootstrap;
        self.bootstrapper.start_l2_sync(self.current_height, target_height);

---

crates/apollo_l1_provider/src/l1_provider_tests.rs line 379 at r2 (raw file):

    l1_provider.initialize(STARTUP_HEIGHT, vec![]).await.expect("l1 provider initialize failed");
    l1_provider.state = ProviderState::Bootstrap;
    l1_provider.bootstrapper.start_l2_sync(STARTUP_HEIGHT, TARGET_HEIGHT);

call that function here

Code quote:

    l1_provider.state = ProviderState::Bootstrap;
    l1_provider.bootstrapper.start_l2_sync(STARTUP_HEIGHT, TARGET_HEIGHT);

[ShahakShama]

@ShahakShama reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @guy-starkware)

[guy-starkware]

@guy-starkware reviewed 2 of 4 files at r3, 2 of 2 files at r4, all commit messages.
@guy-starkware dismissed @sirandreww-starkware from 2 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @guy-starkware)