Implement CacheProvider Trait

[codeZe-us]

The project requires a unified interface for various caching mechanisms to ensure they can be used interchangeably throughout the codebase. The CacheProvider trait will define the standard contract for storing, retrieving, and evicting data, allowing seamless substitution between memory, disk, and Wasm-specific implementations without altering the consuming logic.

Implementation guidelines

• Define the core CacheProvider async trait with get, put, remove, and clear methods.
• Ensure the trait is object-safe or uses generics appropriately for key and value types, bounding them with Send, Sync, Serialize, and Deserialize.
• Include standard error handling definitions for cache misses, capacity limits, and serialization/deserialization failures.

Files location

crates/core/src/cache/provider.rs

Expected result

A robust, reusable trait that abstracts away the underlying storage mechanism, enabling flexible and modular caching solutions across the system.

Please make sure to use the PR template when submitting your pull request.

Join the contributor Telegram group and ask any questions: https://t.me/+sII7WPhll2liMGNk

[Opulencechuks]

I am confident that I can Implement this issue having worked on something similar

[GauravKarakoti]

Allow me to work on this one

[JuliobaCR]

Hi, I'd like to work on this one.

Problem
The cache module currently has no unified abstraction — just a bespoke, disk-only CacheStore (crates/core/src/cache/store.rs, backed by redb) with its own bespoke API. There's no shared contract that lets memory, disk, and Wasm-specific cache implementations (see #403/#404/#405) be swapped interchangeably by the rest of the codebase.

Proposed solution

• Create crates/core/src/cache/provider.rs with an async CacheProvider trait exposing get, put, remove, and clear.
• Use #[async_trait] (or native async-fn-in-trait, matching whatever the existing decode/replay traits in this crate already use, to stay consistent) so it can be implemented by different backends without boxing overhead where avoidable.
• Make it generic over key/value types bounded by Send + Sync + Serialize + DeserializeOwned (serde is already a workspace dependency) rather than trait-object-only, so backends like the planned MemoryCache/DiskCache/WasmCache can pick concrete, efficient types instead of paying for dynamic dispatch everywhere.
• Extend the existing GratError enum (crates/core/src/error.rs) with dedicated variants for cache misses, capacity/size-limit violations, and (de)serialization failures, so all cache backends surface consistent, typed errors instead of ad-hoc strings.
• Add a mockall-style or hand-rolled in-memory test double implementing the trait, plus trait-level tests (get-after-put, remove, clear, miss returns Ok(None) not an error) that any future backend can reuse as a conformance suite.

ETA: 1-2 days.

Will follow the PR template. Since #403/#404/#405 depend on this trait, happy to keep the surface minimal and stable first and iterate, let me know if there's a preferred method signature convention already used elsewhere in the crate.

[grantfox-oss]

🦊 GrantFox — @JuliobaCR has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #402)
2. Your PR will be reviewed by the Toolbox-Lab maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@JuliobaCR's PR #412 was approved and merged by @codeZe-us.

🏆 @JuliobaCR: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (417 total points). Track your full progress on GrantFox.

👏 Great work, @JuliobaCR! Keep contributing to Toolbox-Lab.