Struct InMemoryStore 

pub struct InMemoryStore { /* private fields */ }

Single-node in-memory store: atomic counters behind a short transaction mutex that serializes check-and-spend so multi-key spends stay atomic.

Implementations

impl InMemoryStore

pub fn new() -> Self

Create an empty store.

Trait Implementations

impl Debug for InMemoryStore

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for InMemoryStore

fn default() -> InMemoryStore

Returns the “default value” for a type.

impl StateStore for InMemoryStore

fn refund(&self, key: &str, amount: u64)

Saturating refund. saturating_sub on i64 keeps the value non-negative even under concurrent remove_prefix or a duplicate refund; the transaction lock keeps the load/store pair atomic with respect to other spend / add operations on the same key.

NEVER resurrect a cell that a concurrent remove_prefix already dropped. The prior implementation used self.cell(key) which materialises a fresh 0 AtomicI64 in the DashMap via entry().or_insert_with(...). Under the lost-claim-plus-idle-close ordering (mcp_call’s sandbox-gate debit races with the reconciler’s clear_budget_state), the refund path would create a permanent 0-cell for a sealed session that no future remove_prefix would ever collect — attacker-driven memory growth. Skip the refund silently when the cell is gone; the “budget spent” state is already whatever the caller wanted (probably 0) and there’s nothing to compensate.

fn refund_many(&self, refunds: &[Refund])

R66 F2: fold ALL listed refunds under a single acquisition of transaction_lock so a concurrent try_spend_many (which also holds this lock) cannot observe partial state. Under the old shape (per-key refund), a concurrent try_tool_call running between refund step 1 and step 2 could pass total_calls (freshly refunded) but be refused by the per- tool cap (not yet refunded) — an ordering result impossible under the single-Lua RedisStore path. Now the two backends serialise the batch identically.

fn fetch_max(&self, key: &str, value: u64) -> Result<u64, StateError>

Atomically retain the greater of the stored value and value, returning the resulting maximum. Used for monotonic revocation cutoffs.

fn add(&self, key: &str, delta: u64) -> Result<u64, StateError>

Add delta to key, returning the new value.

fn get(&self, key: &str) -> Result<u64, StateError>

Read the current value of key (0 if absent).

fn try_spend_many( &self, spends: &[Spend], ) -> Result<TrySpendOutcome, StateError>

Atomically validate and commit every spend, or commit none.

fn remove(&self, key: &str)

Remove a key (session cleanup).

fn remove_prefix(&self, prefix: &str)

Remove every key beginning with prefix (whole-session cleanup at finalization). Every backend must implement this: native expiry (e.g. Redis TTLs) is NOT a substitute, because a finalized session id can be recycled into a fresh session within the TTL window and would inherit the prior incarnation’s counters. In-process backends additionally need it or session-keyed counters accumulate for the process lifetime.

fn counter_ttl_secs(&self) -> Option<u64>

Backend counter TTL in seconds, if the backend expires counters natively. None means counters live for the process lifetime (in-memory). Exposing it makes the prod/dev divergence a VALUE callers can inspect (startup logs it; ops docs cite it) instead of a doc comment — a session active longer than this window has its budget counters silently reset against the expiring backend only.

fn try_spend( &self, key: &str, amount: u64, limit: u64, ) -> Result<bool, StateError>

Atomically spend amount from the remaining budget limit - spent(key). Returns Ok(true) and records the spend if the full amount fits, Ok(false) (recording nothing) otherwise.