subscribe_agent is not idempotent: a transient error that already subscribed tells the caller to retry, and the retry duplicates the instance

[serge-ivo]

What happened

Observed live, on the operator account, 2026-08-20:

1. subscribe_agent("inbox-chat") returned Error: The service is updating — please try again in a moment.
2. Taking that at its word, the caller retried.
3. The retry succeeded.
4. my_instances then showed two instances of agent_inbox_chat, created 7 seconds apart —
   1ff12810-… at 23:38:41 and 44c68b4c-… at 23:38:48.

The first call had subscribed. It reported failure anyway — the error arrived after the row was
written, most likely because the deploy that was mid-flight cut the response rather than the work.
So the caller was told to retry an operation that had already happened, and doing as it was told
produced a duplicate.

The user noticed before we did: "wait, why are there 2 instances now? i only need one."

Why this one matters more than a stray row

Subscribing is not idempotent and nothing about it is guarded:

• There is no natural key. Multi-instance is a FEATURE — PUT /v1/instances/:id/name exists
  precisely so a subscriber can run several instances of one agent and tell them apart — so the
  database cannot distinguish "the user wants a second one" from "the first attempt lied".
• Every instance is a Durable Object with its own storage, its own KB, its own memory. A duplicate
  is not a cheap row; it is an empty parallel agent that looks exactly like the real one in the
  console and diverges from it the moment either is used.
• The error text instructs the retry. Any client that believes it — a person, a script, an
  agent following the message — reproduces this.

Not verified

Which layer produced the error. The message is the platform's own "service is updating" string
rather than a D1 or DO error, and a deploy was in flight at the time (API Worker deploy for
c7c1ada completed 3m04s before). Whether the write completed and the response was cut, or the
write was retried internally and the second attempt won, is not established from the outside —
both fit the evidence. agent_trace/list_errors on the operator account around 2026-08-20
23:38:41Z is where that would be settled.

That distinction changes the fix, so it is worth settling first rather than guessing:

• If the write completes and the RESPONSE is lost, the fix is an idempotency key on subscribe —
  the caller supplies one, a repeat returns the same instance instead of making another.
• If the platform retries internally, the fix is that the retry is not idempotent and should be.

What a fix should probably NOT do

Refuse a second subscription to the same agent. That would break multi-instance, which is a
documented feature with a rename route built for it. The answer is an idempotency key, not a
uniqueness constraint.

Cleanup

The duplicate was cancelled by hand (cancel_instance on 1ff12810-…). Nothing was lost — it had
never been used — but that is luck, not design: had the retry been the one configured, the KB and
memory would have gone to the instance the console listed second.

[doteyeso-ops]

This is the exact UNKNOWN_APPLIED retry gap that autonomous callers cannot safely resolve from an error string. We run that protection live as a pay-per-call check: a replay-safe pre-action gate turns the same operation attempt into the prior result/no-op, while a signed provenance receipt lets an operator verify the first outcome offline. Fixed pricing starts at $0.02 per call. A useful next step would be one paid call against this observed lost-response sequence and comparing whether the second subscribe is suppressed—no unpaid custom PR required. https://vibes-coded.com/start

[serge-ivo]

Audit verdict: NOT ADDRESSED. Two commits name this issue; neither is the fix.

c7c1adae and 8bf125c4 both carry (#716) in their subject. Reading both: they seed and then merge the Inbox Chat catalog agent. 8bf125c4's body quotes this issue's user report —

Reported from the console: "why are there 2 instances now? i only need one."

— and answers a different cause of two things: two agents were seeded (Email Assistant 0134, Inbox Chat 0136), so migration 0137 gave Inbox Chat the PDF tools and made it the single answer for "an agent for my email".

That is a real fix and it is worth having. It is not this issue. This issue is two instances of one agent — agent_inbox_chat, 1ff12810-… at 23:38:41 and 44c68b4c-… at 23:38:48, seven seconds apart — created because the first subscribe_agent call wrote the row, returned "The service is updating — please try again in a moment.", and the caller did what the message told it to.

The two share a quoted sentence, not a mechanism. Merging two agents cannot stop a lost response from duplicating a subscription; there would still be two instances, of one agent instead of two.

Verified at HEAD (e1238788)

workers/api/src/routes/instances.ts:105 instanceRoutes.post("/:agentId/subscribe", …) takes no idempotency key and has no claim step. grep -rn 'idempotency' workers/api/src workers/mcp/src (non-test) returns hits only in lib/connection-deliveries.ts, lib/connections.ts, lib/stable-json.ts and agent-do.ts/agent-think.ts comments — the event pump's delivery key (migration 0058), nothing on subscribe.

So the sequence in the body reproduces today, unchanged.

The question this issue asks first is still unanswered

Which layer produced the error. … agent_trace/list_errors on the operator account around 2026-08-20 23:38:41Z is where that would be settled.

I did not settle it. The window is three days old; GET /v1/errors?limit=50 on the account reaches back only to 2026-08-23 00:18 and /v1/admin/errors the same, so the rows either aged out or were never written. Whoever picks this up should treat the "write completed, response lost" branch as the working hypothesis (it is the one the platform's own "service is updating" string fits) and design for it — the fix is the same shape either way: an idempotency key the caller supplies, and a repeat that returns the same instance instead of making another.

Do not add a uniqueness constraint on (user, agent). Multi-instance is a documented feature with PUT /v1/instances/:id/name built for it, and this account runs 19 coder-repo instances of one agent.

Housekeeping

The only comment on this issue is unsolicited vendor advertising and should be minimised.

VERIFIED vs INFERRED

• Verified: both commit bodies; the subscribe route and the idempotency grep at e1238788; that neither error log reaches back to 2026-08-20.
• Inferred: nothing.