What do you do when a tool call times out after a write?
by•
I’m building MELRA, a local runtime for MCP and CLI tools, and I’m testing this recovery edge case: a write may reach the provider even though the agent never gets a response. Retrying can duplicate it, but waiting without a way to reconcile is frustrating. In the current alpha, MELRA parks that attempt until state can be checked. What evidence would you trust before allowing a retry, especially when provider lookups are slow?
42 views
Replies
Before retrying a write, I’d want either a provider idempotency key or an authoritative read that proves the postcondition. A timeout alone is not evidence that the write failed. If the provider lookup is slow, I’d wait with bounded backoff and keep the attempt parked; if the result stays ambiguous or there’s no reliable lookup, leave it for a person to reconcile. MELRA’s alpha records mutating attempts before dispatch and does not replay an uncertain attempt. This avoids duplicates at the cost of automatic progress; it cannot promise exactly-once behavior when the provider offers neither idempotency nor a reliable status check.