How approval prompts can fail and still be recovered

Approval prompts feel simple until one disappears. A technician sends a request, the user was in a meeting, the notification got buried, or the runtime missed the event entirely. Now the session is stuck, the user is confused, and the technician is refreshing a dead screen. This is where most remote support tools leave you with two bad options: abort the session or blindly retry and hope.

Caisey handles this differently. The runtime, the bridge, and the console all maintain independent views of prompt state, and when they drift, reconciliation brings them back together without manual intervention.

Why approval prompts are harder than they look

An approval prompt is a distributed transaction with three parties: the console where the technician initiated it, the bridge that routes messages, and the runtime on the endpoint that actually displays it. Any of these can fail or lag.

The runtime might be offline when the prompt arrives. The bridge might drop a message during a Cloudflare Worker restart. The user might dismiss the notification without making a choice. In traditional tools, these failures often surface as generic timeouts, leaving technicians to guess whether the user ignored them or the infrastructure lost them.

Caisey treats the prompt as a state machine, not a fire-and-forget message. Each state transition—pending, delivered, acknowledged, approved, denied, expired—is tracked and can be queried from any party.

Runtime-side prompt state and missed events

The Caisey runtime maintains its own prompt queue in local state. When a prompt message arrives, the runtime records it before displaying anything. If the display fails—maybe the session was locked, maybe the UI process crashed—the record remains. On reconnection or the next heartbeat, the runtime reports its full prompt state back to the bridge.

This is the first recovery path: the runtime telling the console what it actually has, not the console assuming the runtime got what was sent. If the console shows "pending" but the runtime reports no such prompt, the console knows the message was lost. If the runtime shows "delivered" but the console never got an acknowledgment, the bridge knows it needs to replay.

Bridge error hardening and message replay

Caisey's bridge layer, built on Cloudflare Durable Objects, persists prompt events to SQLite before attempting delivery. This matters because Worker restarts are normal, not exceptional. A prompt in flight during a restart would vanish in a purely in-memory system.

The bridge tracks delivery attempts with exponential backoff. After a failure, it retries with the same event ID. The runtime deduplicates by ID, so replays are safe even if the original message was actually received but the acknowledgment was lost. This symmetric idempotency—safe to send twice, safe to receive twice—is what makes recovery reliable rather than lucky.

When the bridge exhausts retries, it does not silently drop the prompt. It marks it explicitly as failed-to-deliver and surfaces this to the console. The technician sees "could not reach endpoint" rather than an endless spinner. They can choose to retry, escalate, or work with what context they have.

Console-side reconciliation and technician visibility

The console aggregates prompt state from both the bridge and the runtime. When these disagree, it applies reconciliation rules: runtime state wins for local user actions (acknowledged, denied), bridge state wins for delivery status, and console state wins for technician-initiated transitions (cancelled, superseded).

This means a technician can cancel a stuck prompt and issue a new one without fear of the old one suddenly resolving. It means a user who approved on the runtime but the acknowledgment was lost will still have their approval honored when the next heartbeat syncs. It means the system converges to truth rather than requiring perfect real-time connectivity.

Practical recovery scenarios

Consider a technician working with a laptop that suspends mid-session. The prompt was delivered, the user saw it, but before they could respond the machine slept. The runtime records the prompt as delivered but unacknowledged. On wake, the runtime reconnects and reports this state. The console, which had shown "pending" then "timed out," now learns the prompt is still live. The technician sees the updated state and can wait or re-prompt without confusion.

Or consider a bridge restart during a prompt storm—multiple technicians, multiple endpoints, high load. Some prompts are persisted before restart, some are not. After restart, the bridge replays what it has. Runtimes report what they hold. The console reconciles overlaps and gaps. Technicians see accurate state within seconds, not minutes of stale data.

What this means for MSP operations

Explicit recovery paths change how you train technicians. Instead of "if it hangs, restart the session," you get "check the prompt state, see if delivery failed, decide whether to retry or escalate." The tool gives you information to make that decision, not just a timeout to endure.

It also changes your confidence in unattended endpoints. If a prompt expires because the machine was offline, that expiration is recorded and visible. You can see the pattern—this endpoint misses prompts during lunch hours, that user never responds to first prompts—and adjust your workflow rather than treating each failure as unique.

Caisey's approach to prompt recovery is part of a broader design: distributed state that converges, infrastructure that survives restarts, and interfaces that tell you what happened instead of hiding it. For MSPs managing hundreds or thousands of endpoints, this reliability compounds. One recovered prompt saves five minutes. A thousand recovered prompts save days of technician time and user frustration.