Struct InMemoryTaskStore 

pub struct InMemoryTaskStore { /* private fields */ }

In-memory TaskStore backed by a pre-allocated HashMap with secondary indexes under a single RwLock.

Suitable for testing and single-process deployments. Data is lost when the process exits.

The internal HashMap is pre-allocated to the configured max_capacity (default 10,000) to prevent latency spikes from table resizing. Without pre-allocation, HashMap doubles its capacity when load factor exceeds ~87.5%, triggering a full rehash of every stored entry. Pre-allocation eliminates these unpredictable latency cliffs entirely.

Indexing strategy

Index	Structure	Purpose
Primary	HashMap<TaskId, TaskEntry>	O(1) get/save
Order	BTreeMap<u64, TaskId>	O(log n + page_size) update-order pagination
Context	HashMap<String, BTreeMap<u64, TaskId>>	O(log m + page_size) filtered list

The order index is keyed by a monotonic per-write sequence and iterated in reverse to return most-recently-updated tasks first (spec §3.1.4) without the O(n log n) per-call sort that previously caused 20-70× regressions at 10K+ tasks. The context index avoids full-scan filtering by pre-partitioning task IDs by context, preserving the same update-order within each context.

Eviction behavior

Eviction runs every N writes (configurable via TaskStoreConfig::eviction_interval) and whenever the store exceeds max_capacity. If the system goes idle (no save() calls), completed tasks persist in memory past their TTL.

Operators should call run_eviction() periodically (e.g. every 60 seconds via tokio::time::interval) to ensure timely cleanup of terminal tasks during idle periods.

The write that triggers a sweep pays for it

This paragraph used to say the sweep “runs as a background task” and that “writers are not blocked during the O(n) cleanup”. Neither is true and both were corrected on 2026-08-19. There is no spawn: the sweep is awaited inside save, so the caller that triggers it waits for it, and it holds the write lock for its whole duration, so every other writer waits too. What is genuinely decoupled is only the lock acquisition — the insert’s write lock is released before the sweep takes its own.

The size of that, MEASURED (debug profile, tokio multi-thread, 50,000 terminal tasks, eviction_interval 1000):

	latency
quietest of 1,000 consecutive saves	3.99 µs
slowest of the same 1,000 (the one that swept)	4.54 ms

One write in eviction_interval costs about 1,100× a quiet one at that size, and it stalls every concurrent writer, not just itself. The capacity pass is much cheaper — measured 3.5× and 3.7× on two runs at 10,000 entries — because it removes only the overflow rather than scanning for it.

This is a shape to plan for, not a defect to route around: the TTL pass is O(n) unavoidably (finding expired entries means looking at all of them), which is exactly why it is amortized behind eviction_interval rather than run per write. What it means in practice is that eviction_interval is a tail-latency knob as much as a cleanliness one, and that a deployment sensitive to p99.9 write latency should raise it and call run_eviction() from its own scheduler instead — where the stall lands somewhere it chose.

Concurrency

For high-concurrency production deployments, consider SqliteTaskStore which uses a connection pool and row-level locking. The in-memory store uses a single RwLock and is optimized for testing and moderate load.

Implementations

impl InMemoryTaskStore

pub async fn run_eviction(&self)

Runs background eviction of expired and over-capacity entries.

Call this periodically (e.g. every 60 seconds) to clean up terminal tasks that would otherwise persist until the next save() call.

impl InMemoryTaskStore

pub fn new() -> Self

Creates a new empty in-memory task store with default configuration.

Default: max 10,000 tasks, 1-hour TTL for terminal tasks. The internal HashMap is pre-allocated to the configured max_capacity to prevent resize-induced latency spikes during operation.

pub fn with_config(config: TaskStoreConfig) -> Self

Creates a new in-memory task store with custom configuration.

The internal HashMap is pre-allocated to config.max_capacity (or a sensible default if None) to prevent resize-induced latency spikes.

Trait Implementations

impl Debug for InMemoryTaskStore

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

Formats the value using the given formatter.

impl Default for InMemoryTaskStore

fn default() -> Self

Returns the “default value” for a type.

impl TaskStore for InMemoryTaskStore

fn save_artifact_delta<'a>( &'a self, task: &'a Task, delta: ArtifactDelta, ) -> Pin<Box<dyn Future<Output = A2aResult<()>> + Send + 'a>>

Applies the delta to the stored task in place, copying only what grew.

save clones the whole task, so using it per artifact event makes a stream cost quadratic in its own length — see TaskStore::save_artifact_delta for the measurement. Here the work is proportional to the appended parts instead of the accumulated ones.

Falls back to save whenever the stored record is not the one this delta describes: absent, no artifacts, index out of range, a different artifact at that index, or fewer parts present than the delta claims were appended. Those are all “cannot apply safely”, and a whole-record replace is always right — a wrong in-place edit would not be.

fn save<'a>( &'a self, task: &'a Task, ) -> Pin<Box<dyn Future<Output = A2aResult<()>> + Send + 'a>>

Saves (creates or updates) a task.

fn get<'a>( &'a self, id: &'a TaskId, ) -> Pin<Box<dyn Future<Output = A2aResult<Option<Task>>> + Send + 'a>>

Retrieves a task by its ID, returning None if not found.

fn list<'a>( &'a self, params: &'a ListTasksParams, ) -> Pin<Box<dyn Future<Output = A2aResult<TaskListResponse>> + Send + 'a>>

Lists tasks matching the given filter parameters.

fn insert_if_absent<'a>( &'a self, task: &'a Task, ) -> Pin<Box<dyn Future<Output = A2aResult<bool>> + Send + 'a>>

Atomically inserts a task only if no task with the same ID exists.

fn delete<'a>( &'a self, id: &'a TaskId, ) -> Pin<Box<dyn Future<Output = A2aResult<()>> + Send + 'a>>

Deletes a task by its ID.

fn count<'a>( &'a self, ) -> Pin<Box<dyn Future<Output = A2aResult<u64>> + Send + 'a>>

Returns the total number of tasks in the store.