refactor: replace ipfs TimeSizedCache with Moka#4542
Conversation
There was a problem hiding this comment.
Code Review
This pull request replaces the cached crate with moka for caching IPFS app data in the orderbook, which simplifies the code by removing explicit Mutex locking. It also updates a test assertion in the balance overrides crate. The review feedback suggests using moka::future::Cache instead of moka::sync::Cache to perform non-blocking operations in an asynchronous context.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| }; | ||
| let result = self | ||
| .cache | ||
| .try_get_with(*contract_app_data, async { |
There was a problem hiding this comment.
Isn't this performing an extra, unnecessary, get call? Since we already did this and returned earlier in L99
There was a problem hiding this comment.
It could be done in one try_get_with call, though at the expense of altering the metrics. Pushed a small update to make this easier to see. Thoughts?
There was a problem hiding this comment.
Since try_get_with combines get and insert, will not be able to tell source anymore.
There was a problem hiding this comment.
It's still performing the get in L91, why not just keep the logic like it was and use insert instead of the try_get_with? I feel like I'm missing something
There was a problem hiding this comment.
Sure, have updated it to keep original logic. Was just used since multiple callers of the same key would be evaluated once, with the others waiting for the result, if not already found in the first get to the cache.
Description
Replace the existing mutex IPFS cache with Moka.
Changes
Mutex<TimedSizedCache<AppDataHash, Option<String>>>withmoka::future::Cache<AppDataHash, Option<String>>How to test
cargo nextest run