pub struct LiveCache { /* private fields */ }Implementations§
Source§impl LiveCache
impl LiveCache
pub fn new<S: Store + 'static>(store: S) -> Self
pub fn with_workspace<S: Store + 'static>( store: S, workspace_base: impl Into<PathBuf>, ) -> Self
pub fn from_box(store: Box<dyn Store>) -> Self
pub fn from_box_with_workspace( store: Box<dyn Store>, workspace_base: PathBuf, ) -> Self
pub fn store(&self) -> &dyn Store
pub fn workspace_base(&self) -> &Path
pub fn entry_count(&self) -> usize
Sourcepub fn contains(&self, key: &Key) -> bool
pub fn contains(&self, key: &Key) -> bool
Whether an entry for key is present, checking the in-memory registry
first and falling back to the store. Does not fetch or revalidate the
payload, so it is a cheap presence probe (used by provenance telemetry
to count how many tool-result edges in a prompt resolve to a known node).
Sourcepub fn lookup(&self, key: &Key) -> Result<LookupOutcome, CacheError>
pub fn lookup(&self, key: &Key) -> Result<LookupOutcome, CacheError>
Bare lookup with no file revalidation. Used by tools whose output
has no filesystem dependency (rare in M1 — even Bash depends on
the cwd’s contents in practice). Most callers want
lookup_revalidate.
Sourcepub fn lookup_revalidate(&self, key: &Key) -> Result<LookupOutcome, CacheError>
pub fn lookup_revalidate(&self, key: &Key) -> Result<LookupOutcome, CacheError>
Lookup with revalidation: re-blake3 every recorded file root and
require the hash to still match the value captured on persist. On
any mismatch the entry is removed from the registry and Invalidated
is returned so the caller knows to re-execute the real tool.
This is the primary lookup path for read, glob, and grep
tools whose output is a pure function of named file contents. Bash
typically cannot use this path because the set of files Bash
reads is not known a priori.
Sourcepub fn persist(
&self,
key: &Key,
bytes: &[u8],
tool_kind: &str,
file_roots: Vec<FileRoot>,
) -> Result<(), CacheError>
pub fn persist( &self, key: &Key, bytes: &[u8], tool_kind: &str, file_roots: Vec<FileRoot>, ) -> Result<(), CacheError>
Record a fresh tool execution. Caller has already produced the
formatted output bytes the model will see; we persist them under
key and register the file roots for future revalidation.
Sourcepub fn persist_with_upstreams(
&self,
key: &Key,
bytes: &[u8],
tool_kind: &str,
file_roots: Vec<FileRoot>,
upstream_keys: Vec<Key>,
) -> Result<(), CacheError>
pub fn persist_with_upstreams( &self, key: &Key, bytes: &[u8], tool_kind: &str, file_roots: Vec<FileRoot>, upstream_keys: Vec<Key>, ) -> Result<(), CacheError>
Persist an entry whose validity depends on the listed upstream cache keys. The proxy’s LlmCall path uses this so a tool-cache invalidation can walk the upstream edge and drop dependent completions.
Sourcepub fn mark_dirty(&self, key: &Key)
pub fn mark_dirty(&self, key: &Key)
Drop the registry entry for key. The store payload remains on
disk (M1 is append-only; M2 adds eviction) but subsequent lookups
will Miss because the registry is the authoritative gate.
Used by write and edit MCP tools to invalidate every cached
node whose path matches the written path; the verdant-mcp layer
computes the affected key set and calls this for each.
Sourcepub fn invalidate_upstream(&self, upstream_key: &Key) -> usize
pub fn invalidate_upstream(&self, upstream_key: &Key) -> usize
Drop every cache entry that depends on upstream_key either
directly (its upstream_keys includes that hex) or transitively
(its dependency closure does). Returns the number of entries
dropped.
This is the cross-layer dirty propagation path that ties the
M3 LlmCall cache to M1’s tool cache: when a read entry is
invalidated by invalidate_path, the proxy calls this with
the read’s key and every LlmCall whose prompt consumed that
read drops out of the cache. Without this hop, an edited file
would silently feed the model the old bytes via a stale cached
completion.
Sourcepub fn invalidate_path(&self, path: &Path) -> usize
pub fn invalidate_path(&self, path: &Path) -> usize
Drop every cached entry whose recorded file roots include path, then
cascade up the dependency edges. Scans the persisted store metadata so
the effect is visible across processes sharing the store. O(n) in store
size; the code anticipates a future path -> keys index.