store: the A2A task store and the MCP call log are durable, and a reconnect is what proves it

[MattJackson]

Closes the A2A goal item D.19 for this backend, plus the same-defect-class gap in the MCP tool-call log.

The defect

busbar_api::Store has ten methods whose defaults are accept and keep nothing — put_task/append_task_event/append_mcp_call return Ok(()), get_task returns None, the list_* methods return empty. This backend overrode none of them. Every in-flight A2A task, and every MCP tool-call record, was lost on every restart, and nothing anywhere reported it: the return value of a write is not evidence that anything was stored.

The data model, and where it honestly diverges

There are no columns here, so the SQL backends' "every field its own column" becomes "the value is the row": one string per task holding the row as JSON, plus a SET indexing every task id so list_tasks — defined by the contract as returning every row, unfiltered — is one SMEMBERS rather than a keyspace SCAN on the hot path of a boot rehydrate. Row and index entry land in one atomic pipeline.

Three places this backend cannot or should not mirror the SQL ones, called out rather than papered over:

• Events live in a HASH, not a seq-scored ZSET. A ZSET score is an IEEE-754 double, so a seq above 2^53 would silently collide with its neighbours. HSET is also natively the upsert-on-(task_id, seq) the contract requires, where a scored ZSET reaches it only via remove-then-add. Cost: chain order is restored in-process, sorted numerically — the field names are decimal strings, and a lexicographic sort would put seq 10 before seq 2 and hand the verifier a chain that appears not to link.
• Retention does a full pass over the task rows rather than reading a scored index. A ZSET scored by updated_at hits the same double hazard; no score can express "terminal" so the row must be read anyway; and list_tasks is already an every-row read the rehydrate performs routinely, so this is not a new cost class — and it is exact.
• No out-of-range guard, deliberately. sqlite/postgres/mysql store these counters in a signed 64-bit column and must refuse a u64 above i64::MAX. Here the row is JSON, where a u64 is exact across its whole range, so a refusal would be inventing a limit this backend does not have. The boundary is proven the other way round instead: u64::MAX goes in and comes back out unchanged.

append_task_event upserts, which is where the task contract genuinely differs from append_mcp_call's fork check a few methods up the same file. Copying that check here would have been wrong in a way that looks right.

.busbar-ref

Bumped from c8780349 (1.5.3) to 5a4f0195, the dev commit that carries both contracts — the old pin predates them and would not compile these methods. The engine-side diff of crates/api between the two is purely additive: TaskRow, TaskEventRow, and six defaulted trait methods. ci.yml is unchanged and still builds against the same-named core branch.

How this was verified

Red before green. All 7 task tests were run first against the unimplemented state and seen to fail, headline got None back from a new connection.

The property is "it survives a restart." The durability tests drop the store — closing its connection entirely — then connect a genuinely new one and read the row back off the server. A round-trip on one live handle cannot distinguish a real write from a HashMap behind the same trait.

A test-only fix rides along

purge_mcp_calls_before and purge_tasks_before are global by timestamp — that is the contract, not a shortcut — and this suite deliberately shares one Valkey without wiping, isolating by key namespace. A sweep does not name the rows it removes, so namespace isolation cannot help it: one test's purge deleted another test's records between that test's append and its read. It presented as "retention quietly removed nothing" and it moved from one test to another as the timestamp bands were shuffled, which is how it was diagnosed. The sweeping tests now serialise against each other; the non-sweeping ones place their rows above every cutoff. Failed ~1 run in 2 before; 9 consecutive green runs after.

Gates run locally

gate	result
public-hygiene-lint --selftest / --root	pass, 0 hits
cargo fmt --all -- --check	pass
cargo build --all-targets	pass
cargo clippy --all-targets -- -D warnings	pass
cargo test (lib, real Valkey 8)	52 passed, 3 ignored — 9 consecutive runs
executable-config-lint --selftest / --root	pass, 2 valid