Question
What recovery/reconciliation behavior should a caller expect in standalone SQLite mode after the server dies between an MCP effect committing and the corresponding tool.response being persisted?
I measured this against @truefoundry/trueforge@0.1.4 using a deterministic local model endpoint, a harmless MCP effect, and an out-of-process effect ledger. The recovery step is an explicit application-issued successor turn, not automatic TrueForge recovery.
Source, evidence, limitations, and verification commands
Observations
The historical matrix contains 180 trials: three boundaries, two receiver modes, 30 per cell.
| Boundary |
Naive receiver: final effects |
Idempotent receiver: final effects |
| No crash |
1 in 30/30 |
1 in 30/30 |
| Before effect commit, then explicit retry |
1 in 30/30 |
1 in 30/30 |
| After effect commit / before response, then explicit retry |
2 in 30/30 |
1 in 30/30 |
The current validator re-derives all 180 measured outcomes from retained raw ledger rows. That older bundle predates the newer source-binding/incremental-log contract and therefore does not receive a complete strict-admission PASS. A separately recorded six-trial smoke bundle, one trial per cell, matches this matrix and does pass the full current contract. Both are published separately; the historical files were not backfilled.
Scope and proposed documentation boundary
This does not establish hosted Postgres/Redis behavior, real-provider behavior, or a global exactly-once guarantee. It also does not imply an arbitrary retry is safe merely because one pre-effect fixture completed once.
Would you consider documenting how callers should identify/reconcile unresolved MCP effects before initiating a successor turn? If there is already a supported recovery API or documented procedure for this version, I would appreciate a pointer so I can evaluate that path separately. This is a bounded behavioral report and documentation question, not a claim that TrueForge promises exactly-once external effects.
Question
What recovery/reconciliation behavior should a caller expect in standalone SQLite mode after the server dies between an MCP effect committing and the corresponding
tool.responsebeing persisted?I measured this against
@truefoundry/trueforge@0.1.4using a deterministic local model endpoint, a harmless MCP effect, and an out-of-process effect ledger. The recovery step is an explicit application-issued successor turn, not automatic TrueForge recovery.Source, evidence, limitations, and verification commands
Observations
The historical matrix contains 180 trials: three boundaries, two receiver modes, 30 per cell.
The current validator re-derives all 180 measured outcomes from retained raw ledger rows. That older bundle predates the newer source-binding/incremental-log contract and therefore does not receive a complete strict-admission PASS. A separately recorded six-trial smoke bundle, one trial per cell, matches this matrix and does pass the full current contract. Both are published separately; the historical files were not backfilled.
Scope and proposed documentation boundary
This does not establish hosted Postgres/Redis behavior, real-provider behavior, or a global exactly-once guarantee. It also does not imply an arbitrary retry is safe merely because one pre-effect fixture completed once.
Would you consider documenting how callers should identify/reconcile unresolved MCP effects before initiating a successor turn? If there is already a supported recovery API or documented procedure for this version, I would appreciate a pointer so I can evaluate that path separately. This is a bounded behavioral report and documentation question, not a claim that TrueForge promises exactly-once external effects.