fix(matrix-bridge): land terminal frame before silent deleteAll + admin/debug endpoints

[replicas-connector]

Summary

Started as two diagnostic endpoints. Surveying joined_rooms vs KV mappings then pulling room timelines surfaced the actual root cause of many group chats are stuck: two silent deleteAll paths in the poller. Now this PR also patches that.

Root cause of "stuck" rooms

ReplicaPoller.alarmInner had two paths that wiped DO state without first landing a terminal frame on the user-facing status pane. Whatever frame had last rendered (e.g. Editing · step 9 · 1:15) stayed pinned forever, looking stuck:

1. MAX_WATCH_DURATION_MS (30 min) — long-running watches got their DO state wiped while the pane stayed on the last Planning/Editing frame. Fix: lands a Failed frame "Watch timed out — agent ran longer than 30 min." then deletes.

2. /history 404/410 — when the upstream Replicas-side replica vanished (TTL expiry, manual delete, transient error), the poller silently wiped state. The user saw a frozen pane with no signal to resend. Fix: lands a Failed frame "Replica gone (upstream returned ). Send a new message to start a fresh session." then deletes.

Verified the symptom on three Beeper rooms (Jessica Butler, Travel Manager, Adult Admin) whose last bot-rendered frame was mid-progress from a watch that hit one of these paths.

Diagnostic endpoints (used to find the bug)

• GET /debug/joined-rooms — bot's full joined room set, surfaces rooms-not-in-KV.
• GET /debug/room-timeline/:roomId?limit=N — recent timeline events for a room.
• GET /debug/roomname/:roomId — resolves a Matrix room id to its display name.
• POST /admin/watcher/:replicaId/cancel — proxies to the watcher DO's /cancel, terminates the replica and lands a "Cancelled by user" frame. Used today to unstick the runaway Project Nomad Office session.

Test plan

• Typecheck clean
• bun test src/render.test.ts — 48/48 pass
• Deployed (Worker version 63e47db6-55fd-4891-84b3-ace8ccca3de6)
• Verified /debug/joined-rooms returns 16 rooms vs 8 in KV → identified the gap
• Verified POST /admin/watcher/.../cancel on Project Nomad Office → pendingCleanup set, terminal frame rendered
• Currently-stuck panes (3 rooms) will resolve on next user message via the new terminal-frame paths; could backfill with a one-shot cleanup script if desired

---

_{Created by Jaden (jadengarza@pm.me) with Replicas
Workspace  ·  Slack Thread}

[capy-ai]

Capy auto-review is paused for this organization because the monthly auto-review limit has been reached. Increase the limit or turn it off in billing settings to resume automatic reviews.

[devin-ai-integration]

Devin Review found 1 potential issue.

View 6 additional findings in Devin Review.

[devin-ai-integration]

🟡 Missing Content-Type: application/json header on Matrix bridge Replicas API POST calls

The replicasHeaders() function in replicas-matrix-bridge/src/dispatch.ts:221-226 does not include "Content-Type": "application/json", but it is used as the headers for the POST /replica call (dispatch.ts:176-179) and the POST /replica/{id}/messages call (dispatch.ts:147-151), both of which send JSON.stringify()'d bodies. Without the explicit Content-Type, Cloudflare Workers defaults the header to text/plain;charset=UTF-8 for string bodies, which may cause the Replicas API to misparse or reject the request.

The sibling Telegram bridge correctly includes the header in its equivalent function (replicas-telegram-bridge/src/index.ts:339-344). This inconsistency means the Matrix bridge is sending JSON payloads with the wrong Content-Type for replica creation and follow-up messages.

Suggested change

	function replicasHeaders(env: Env): HeadersInit {
	return {
	Authorization: `Bearer ${env.REPLICAS_API_KEY}`,
	"Replicas-Org-Id": env.REPLICAS_ORG_ID,
	};
	}
	function replicasHeaders(env: Env): HeadersInit {
	return {
	Authorization: `Bearer ${env.REPLICAS_API_KEY}`,
	"Replicas-Org-Id": env.REPLICAS_ORG_ID,
	"Content-Type": "application/json",
	};
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[replicas-connector]

🟡 Missing Content-Type: application/json header on Matrix bridge Replicas API POST calls

The replicasHeaders() function in replicas-matrix-bridge/src/dispatch.ts:221-226 does not include "Content-Type": "application/json", but it is used as the headers for the POST /replica call (dispatch.ts:176-179) and the POST /replica/{id}/messages call (dispatch.ts:147-151), both of which send JSON.stringify()'d bodies. Without the explicit Content-Type, Cloudflare Workers defaults the header to text/plain;charset=UTF-8 for string bodies, which may cause the Replicas API to misparse or reject the request.

The sibling Telegram bridge correctly includes the header in its equivalent function (replicas-telegram-bridge/src/index.ts:339-344). This inconsistency means the Matrix bridge is sending JSON payloads with the wrong Content-Type for replica creation and follow-up messages.

Suggested change

	function replicasHeaders(env: Env): HeadersInit {
	return {
	Authorization: `Bearer ${env.REPLICAS_API_KEY}`,
	"Replicas-Org-Id": env.REPLICAS_ORG_ID,
	};
	}
	function replicasHeaders(env: Env): HeadersInit {
	return {
	Authorization: `Bearer ${env.REPLICAS_API_KEY}`,
	"Replicas-Org-Id": env.REPLICAS_ORG_ID,
	"Content-Type": "application/json",
	};
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

@devin-ai-integration[bot] This repository is not connected to a Replicas organization.

To enable Replicas on this repository:

1. Go to GitHub integration settings
2. Add this repository to your organization

Note: Each repository can only be connected to one Replicas organization.

[replicas-connector]

Devin Review found 1 potential issue.

View 6 additional findings in Devin Review.

@devin-ai-integration[bot] This repository is not connected to a Replicas organization.

To enable Replicas on this repository:

1. Go to GitHub integration settings
2. Add this repository to your organization

Note: Each repository can only be connected to one Replicas organization.