feat(sync): central class cache

[dan-starkware]

Pull Request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this introduce a breaking change?

• Yes
• No

Other information

---

This change is 

[codecov]

Codecov Report

Merging #1279 (0ce1048) into main (32bf727) will increase coverage by 0.00%.
Report is 2 commits behind head on main.
The diff coverage is 75.00%.

@@           Coverage Diff           @@
##             main    #1279   +/-   ##
=======================================
  Coverage   72.99%   73.00%           
=======================================
  Files          84       84           
  Lines        7950     7967   +17     
  Branches     7950     7967   +17     
=======================================
+ Hits         5803     5816   +13     
- Misses       1224     1229    +5     
+ Partials      923      922    -1     

Files	Coverage Δ
...us_sync/src/sources/central/state_update_stream.rs	91.26% <100.00%> (+0.15%)	⬆️
crates/papyrus_sync/src/sources/central.rs	75.60% <66.66%> (-0.46%)	⬇️

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ShahakShama]

Reviewed 8 of 8 files at r1, all commit messages.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @dan-starkware)

---

config/default_config.json line 13 at r1 (raw file):

  },
  "central.class_cache_size": {
    "description": "Size of class cache, must be a natural number.",

Not everyone's a mathematician (and within the mathematicians there's a debate if 0 is natural)
Write positive and/or non-zero instead

---

crates/papyrus_sync/src/sources/central.rs line 40 at r1 (raw file):

};
use starknet_client::{ClientCreationError, RetryConfig};
use tokio::sync::Mutex;

Describe in a comment why do we use tokio mutex and not std

---

crates/papyrus_sync/src/sources/central.rs line 55 at r1 (raw file):

    pub max_state_updates_to_store_in_memory: usize,
    pub max_classes_to_download: usize,
    // TODO(dan): validate that class_cache_size is a natural number.

Same here

---

crates/papyrus_sync/src/sources/central.rs line 69 at r1 (raw file):

            max_state_updates_to_store_in_memory: 20,
            max_classes_to_download: 20,
            class_cache_size: 30,

Does it make sense that class_cache_size is bigger than max_classes_to_download?

---

crates/papyrus_sync/src/sources/central.rs line 122 at r1 (raw file):

                "class_cache_size",
                &self.class_cache_size,
                "Size of class cache, must be a natural number.",

Same here

---

crates/papyrus_sync/src/sources/central_test.rs line 457 at r1 (raw file):

fn get_test_class_cache() -> Arc<Mutex<LruCache<ClassHash, ApiContractClass>>> {
    Arc::from(Mutex::new(LruCache::new(NonZeroUsize::new(2).expect("2 should not be zero."))))

IMO you can unwrap here instead of writing this message

[dan-starkware]

Reviewable status: 5 of 8 files reviewed, 4 unresolved discussions (waiting on @ShahakShama)

---

config/default_config.json line 13 at r1 (raw file):

Previously, ShahakShama wrote…

Not everyone's a mathematician (and within the mathematicians there's a debate if 0 is natural)
Write positive and/or non-zero instead

Done.

---

crates/papyrus_sync/src/sources/central.rs line 40 at r1 (raw file):

Previously, ShahakShama wrote…

Describe in a comment why do we use tokio mutex and not std

IMO it is clear from the code. Can you suggest a comment?

---

crates/papyrus_sync/src/sources/central.rs line 69 at r1 (raw file):

Previously, ShahakShama wrote…

Does it make sense that class_cache_size is bigger than max_classes_to_download?

Yes

---

crates/papyrus_sync/src/sources/central_test.rs line 457 at r1 (raw file):

Previously, ShahakShama wrote…

IMO you can unwrap here instead of writing this message

copilot :)

[ShahakShama]

Reviewed 3 of 3 files at r2.
Reviewable status: all files reviewed (commit messages unreviewed), 1 unresolved discussion (waiting on @dan-starkware)

---

crates/papyrus_sync/src/sources/central.rs line 40 at r1 (raw file):

Previously, dan-starkware wrote…

IMO it is clear from the code. Can you suggest a comment?

I don't know what's the reason 😅

[dan-starkware]

Reviewable status: 4 of 8 files reviewed, 1 unresolved discussion (waiting on @ShahakShama)

---

crates/papyrus_sync/src/sources/central.rs line 40 at r1 (raw file):

Previously, ShahakShama wrote…

I don't know what's the reason 😅

Reconsidered, since we don't lock across await and waiting for the lock shouldn't take much time I switched to sync::Mutex

[ShahakShama]

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