What causes "[agent] replay read_run_status failed run_id={run_id}: {e}" in tinyhumansai/openhuman?

Verify the workspace path and its permissions

[agent] replay read_run_status failed run_id={run_id}: {e}

Error message

[agent] replay read_run_status failed run_id={run_id}: {e}

What it means

Replay status lookup failed: FileStatusStore::get_status(run_id) on the workspace kv store errored (replay/ops.rs:105). Same storage class as the journal read — the per-workspace key-value store backing durable HarnessRunStatus could not be opened or read. A run that is simply unknown returns Ok(None), not this error; this error means the store itself was unreadable.

Source

Thrown at src/openhuman/agent/tinyagents/replay/ops.rs:105

    Ok(RunEventsPage {
        events,
        next_offset,
    })
}

/// Latest durable [`HarnessRunStatus`] for `run_id`, or `None` when the run is
/// unknown. Backed by the C4 status seam
/// ([`crate::openhuman::agent::tinyagents::journal::read_run_status`] /
/// [`FileStatusStore::get_status`]).
pub(crate) async fn read_run_status(
    workspace: &Path,
    run_id: &str,
) -> anyhow::Result<Option<HarnessRunStatus>> {
    log::debug!("[agent] replay read_run_status run_id={run_id}");
    let stores = open_session_stores(workspace);
    let store = FileStatusStore::new(stores.kv);
    let status = store.get_status(run_id).await.map_err(|e| {
        anyhow::anyhow!("[agent] replay read_run_status failed run_id={run_id}: {e}")
    })?;
    log::debug!(
        "[agent] replay read_run_status run_id={run_id} found={}",
        status.is_some()
    );
    Ok(status)
}

/// Is a run still live (i.e. eligible for the "active" listing)?
///
/// Mirrors the liveness predicate the crate's status store uses for
/// `list_active` (Pending / Running / Interrupted).
fn is_active(status: &HarnessRunStatus) -> bool {
    matches!(
        status.status,
        ExecutionStatus::Pending | ExecutionStatus::Running | ExecutionStatus::Interrupted
    )
}

View on GitHub (pinned to a221052e0d)

Solutions

Verify the workspace path and its permissions
Retry once the owning process stops writing (transient sqlite busy)
Check whether the status store file was truncated/corrupted (crash mid-write) and rebuild the workspace session stores if so
Ensure only one core process uses the workspace

Defensive patterns

Strategy: retry

Validate before calling

if std::fs::metadata(workspace).is_err() {
    anyhow::bail!("workspace missing at {} — cannot read run status", workspace.display());
}

Try / catch

// Treat as transient-first: retry busy, surface missing-workspace distinctly
match read_run_status(workspace, run_id).await {
    Ok(s) => s,
    Err(e) if e.to_string().contains("busy") => retry_after_backoff().await,
    Err(e) => return Err(anyhow!("status store unreadable for {run_id}: {e:#}")),
}

Prevention

Remember Ok(None) means unknown run; only Err means store trouble — log them differently
Keep status queries off hot loops while a run is persisting status updates
Back up and restore workspaces atomically to avoid truncated kv stores

When it happens

Trigger: Missing/moved workspace directory; kv store file locked by a concurrent writer; corrupted status store after a crash; permission or read-only-mount issues on the workspace.

Common situations: Querying run status while the core is actively persisting status updates; moving or copying workspace dirs between machines; containerized runs with mismatched volume permissions.

Related errors

AI-assisted analysis of tinyhumansai/openhuman@a221052e0d (2026-08-16). Data as JSON: /api/errors/6b223968dca8f0dc. Report an issue: GitHub.