tinyhumansai/openhuman · error
memory_store: {e}
Error message
memory_store: {e} What it means
Generic wrapper around the actual memory-store write for `memory_store`: inputs passed all guards (non-empty key, content not secret-like) but persisting the entry through the memory driver failed. The `{e}` detail identifies the failing layer — store I/O, module transport, or category handling.
Source
Thrown at src/openhuman/memory/tools/store.rs:129
return Ok(ToolResult::error("key cannot be empty".to_string()));
}
if safety::has_likely_secret(content) {
log::warn!(
"[memory:safety] memory_store rejected secret-like content namespace_chars={} key_chars={} content_chars={}",
namespace.chars().count(),
key.chars().count(),
content.chars().count()
);
return Ok(ToolResult::error(
"Refusing to store content that looks like a secret. Remove credentials or tokens and try again.".to_string(),
));
}
let display_key = format!("{namespace}/{key}");
let guard = active_memory_guard()
.await
.map_err(|e| anyhow::anyhow!("memory_store: {e}"))?;
match guard
.store(
namespace,
key,
content,
category,
None,
// Requested provenance; the guard stamps the effective value.
MemoryTaint::default(),
)
.await
{
Ok(()) => Ok(ToolResult::success(format!("Stored memory: {display_key}"))),
Err(e) => Ok(ToolResult::error(format!("Failed to store memory: {e}"))),
}
}
}
View on GitHub (pinned to 7491200858)
Solutions
- Inspect `{e}` for the store-layer cause
- Retry once for transient store/module faults
- Check memory store health and workspace permissions
- Use a standard category ('core', 'daily', 'conversation') if the detail implicates category handling
Defensive patterns
Strategy: retry
When it happens
Trigger: Thrown at src/openhuman/memory/tools/store.rs:129 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17).
Data as JSON: /api/errors/86c4062d15e029cb.
Report an issue: GitHub.