One effect and a refused retry when the answer is lost: managed execution with a contract provider
With the MCP answer lost after the effect, the provider held 1 payment and the retry was refused as undetermined; with the request cut before the server, 0 payments and a reservation an operator act could resolve.
Prediction heldDoes it work?Working note
- Designed for
- Built to test whether, when the answer to an effectful call is lost or the request is cut before the server, the guard keeps exactly one effect, refuses the retry and gives the operator a way to resolve the hold.
What was tested
Integration tests used a stdio relay that forwards part of an exchange, then kills the server, on the guard’s managed execution path in front of a service with a contract test provider and a disposable database. They read the provider ledger, domain tables, authority and intent store, with a delivered-answer row and negative controls. No language model ran.
What we observed
With the MCP answer lost, the provider held 1 payment; 1,500 budget units stayed reserved with the attempt marked as possibly entered, the intent was claimed, and the retry was refused as undetermined, with no frame resent. With the request cut before the server, there were 0 payments and 1,500 reserved, which a new operator act could resolve. A same-day CI run executed the acceptance tests: 193 passed, 0 skipped.
What this means for Heimdall
Keeping one effect meant holding an unknown for an operator instead of retrying. Its result bears on the executor’s record-before-effect rule and the unknown status.
Limits
A contract provider only; kills inside the payment write and commits were not measured; model-level retries are not covered; the whole CI workflow was not green; the tests now live in another repository.
What remains open
Rerun the scenarios against today’s gateway.