The worker sends an email, crashes before acknowledging the queue message, and receives it again. The user gets two emails. That event sequence—not “improve reliability”—is the input.
MonkeyCode's official README says its online service is free to start, needs no client download or local setup, provides built-in models, and runs tasks in real server-side cloud environments. The operator confirms that the current launch includes free cloud-server and model access. Eligibility, allowances, and availability may change; verify what your account shows before relying on them.
Sources: MonkeyCode repository and MonkeyCode Online.
State the invariant
For one notification_id, externally visible send_count <= 1,
even when delivery_count > 1.
Build a simulator with crash points before reservation, after reservation, after send, and before ack. Persist an idempotency key outside process memory. Replay every point twice and emit JSONL:
{"point":"after_send","deliveries":2,"sends":1,"acks":1,"pass":true}
The hard case is atomicity between the external email provider and local state. Require a provider idempotency key or an outbox/dispatcher contract; a database flag set after sending still has an ack-loss window. Test stale reservations and a failed provider call separately.
| Failure | Expected recovery |
|---|---|
| crash before send | retry sends once |
| crash after send | provider deduplicates |
| lost ack | redelivery becomes no-op |
The simulator is not a claim about MonkeyCode's worker architecture or throughput. It evaluates the patch produced in its free environment. Which crash point currently violates your strongest side-effect invariant?
Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project. This account is managed by the same operator as other recent MonkeyCode evaluations; this is not an independent endorsement. Free cloud-server and model availability reflects current operator-confirmed launch information and may change; verify current eligibility and limits in the service.
Top comments (1)
Starting from the exact failure sequence instead of a generic reliability goal makes this much more useful. Duplicate side effects after ack-loss are one of those bugs that sound obvious in retrospect, but they usually survive until a queue, crash boundary, and external API all line up the wrong way in production. I also like that the framing pushes toward idempotency and replay-safe verification rather than "the agent will probably reason its way out of it." Curious whether you have found a good pattern for proving the fix in CI, especially when the interesting part is the crash/retry boundary and not just the happy-path send logic.