---
status: resolved
opened: 2026-08-31
located-in: [mesh-host]
fixed-by: mesh-host — the store's readiness is checked over TCP, not the socket
amended-design:
---

# 017 — An action succeeded into a state its own verify rejects

## Symptom

The substrate's `store-ready` action waits for the store to answer, then the host runs the
action's `verify` to read back that it worked. Intermittently the host reported:

> the action ran without error and its own verify still fails

Both statements were true. The action waited on the **unix socket**; its verify checked the same
way, a moment later, and found nothing. Roughly one bootstrap in three.

## Why this matters

**The action and its verify were asking different questions without appearing to.** While the
store initialises it runs a temporary server on the socket only, then stops it and starts the real
one. The action's loop saw the temporary server and exited happy; the verify landed in the gap
between the two.

So an action can **succeed into a state its own verify rejects** — and when it does, the host's
report is accurate and useless. It says the command worked and the read-back did not, which is
exactly what the mechanism is for, and names nothing a person can act on. It read as a slow
machine, and the remedy people reach for is a longer timeout, which cannot help.

**The general rule, which the host's design should carry:** an action's verify is the *definition*
of what the action is for. If the action's own waiting decides it is done by a different test than
the verify uses, the two can disagree — and the disagreement surfaces as an intermittent failure
in the one place designed to catch silent success.

## What was done

Both check the store over TCP, which the init phase deliberately does not open — so neither can
mistake the temporary server for the real one, and neither can be satisfied while the other is not.

*Checked by the bootstrap itself, which is where it failed: this action gates everything after it,
so a mesh coming up at all is the check.*