zeroclaw-labs/zeroclaw · error · anyhow::Error

purge_session_for_agent not supported by this memory backend

Error message

purge_session_for_agent not supported by this memory backend

What it means

expected_sha256_for_asset (src/commands/update.rs:557) parses SHA256SUMS lines in the coreutils format `<64-hex-digest> <filename>` (with an optional `*` binary-mode marker on the name). This bail fires when the line matching the asset is malformed: either there are extra tokens after the filename (parts.next().is_some()), or the digest is not exactly 64 ASCII hex characters (is_sha256_hex). It is a validation failure of the published checksum file itself — the download's integrity was never assessed. Distinct from the neighboring "asset not found in SHA256SUMS" bail for a missing entry.

Source

Thrown at crates/zeroclaw-api/src/memory_traits.rs:341

    /// Remove all memories in a session.
    /// Returns the number of deleted entries.
    /// Default: returns unsupported error. Backends that support bulk deletion override this.
    async fn purge_session(&self, _session_id: &str) -> anyhow::Result<usize> {
        anyhow::bail!("purge_session not supported by this memory backend")
    }

    /// Remove all memories in a session for one agent.
    /// Returns the number of deleted entries.
    /// Default: returns unsupported error. Backends with per-agent storage
    /// override this; agent-scoped wrappers use it instead of composing a
    /// session list with key-only deletes.
    async fn purge_session_for_agent(
        &self,
        _session_id: &str,
        _agent_id: &str,
    ) -> anyhow::Result<usize> {
        anyhow::bail!("purge_session_for_agent not supported by this memory backend")
    }

    /// Remove every memory row attributed to the given agent alias.
    /// Returns the number of deleted entries. Called when an agent alias is
    /// removed from `[agents.<alias>]` so the database doesn't accumulate
    /// rows for retired aliases.
    /// Default: returns unsupported error. Backends with per-agent storage
    /// (sqlite, postgres) override this; backends without (markdown, none)
    /// keep the default and the caller logs a warning.
    async fn purge_agent(&self, _agent_alias: &str) -> anyhow::Result<usize> {
        anyhow::bail!("purge_agent not supported by this memory backend")
    }

    /// Export every memory row attributed to `agent_alias`, for the agent-
    /// deletion archive (export-then-delete,). Pairs with
    /// [`Self::purge_agent`]: the surface exports these rows to the archive,
    /// then purges. Default: empty (backends without per-agent export).
    async fn export_agent(&self, _agent_alias: &str) -> anyhow::Result<Vec<MemoryEntry>> {

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Fetch the SHA256SUMS from the release page and inspect the line for your asset — confirm it has exactly two whitespace-separated fields and a 64-char hex digest
  2. If you maintain the release: regenerate with coreutils `sha256sum <asset> > SHA256SUMS` in the directory holding the assets and re-upload
  3. If you are a consumer: the release packaging is broken — report it and update to a fixed release; manually verifying the hash is fine for triage but the updater will keep rejecting this release
  4. Pin to the previous known-good release with `zeroclaw update --version <good-tag>` in the meantime

Example fix

# before (published SHA256SUMS — malformed line)
9f2ac...e3 zeroclaw-x86_64-unknown-linux-gnu.tar.gz built-by-ci

# after (maintainer fix: regenerate in coreutils format)
$ cd release-assets/
$ sha256sum zeroclaw-x86_64-unknown-linux-gnu.tar.gz > SHA256SUMS
$ cat SHA256SUMS
9f2ac...e3  zeroclaw-x86_64-unknown-linux-gnu.tar.gz
Defensive patterns

Strategy: validation

Validate before calling

// Pre-parse the sums file exactly like expected_sha256_for_asset before
// starting an update, so a malformed release fails fast with context.
fn sums_entry_valid(sums_text: &str, asset_name: &str) -> bool {
    sums_text.lines().any(|line| {
        let mut parts = line.split_whitespace();
        let (Some(digest), Some(name)) = (parts.next(), parts.next()) else {
            return false;
        };
        parts.next().is_none()
            && name.trim_start_matches('*') == asset_name
            && digest.len() == 64
            && digest.bytes().all(|b| b.is_ascii_hexdigit())
    })
}

Try / catch

if let Err(e) = update::run(version, force).await {
    if e.to_string().contains("invalid SHA256SUMS entry") {
        // Packaging bug in the release, not a network problem:
        // do NOT retry. Pin a known-good --version and report the
        // malformed checksum file to the maintainers.
    }
}

Prevention

When it happens

Trigger: `zeroclaw update` on a release whose SHA256SUMS contains a non-conforming line for the platform asset: an extra column after the filename, a BLAKE2/SHA-512 digest, or a truncated hash. Any generator other than coreutils `sha256sum` (or hand-edited files) can produce such lines.

Common situations: CI generating checksums with the wrong tool (b2sum, shasum -a 512) or appending build metadata columns; a hand-edited SHA256SUMS during a hotfix re-upload; release tooling that writes `digest file extra` rows.

Related errors

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/9a979bd93fb67a84. Report an issue: GitHub.