Offline writes and uncertain outcomes

Reconcile writes without silently replaying payloads.

Handle a lost connection according to what you know about the request’s outcome.

Classify the outcome

RELKIT has no implicit offline write queue. A known-offline write is not-sent; a lost response after transmission is unknown. Agent runs, controls, and continuations use scoped operation IDs and durable receipt lookup after refresh. Arbitrary mutations remain unknown unless the application supplies a reconciliation endpoint. Do not resubmit an uncertain external effect automatically.

Job submissions additionally retain the original operation ID, idempotency key, request digest, and any provider-certified recovery window. A recovered job must use the same request; a discarded runId is not a safe recovery strategy.

Choose recovery from the outcome

The public isJobUnknownOutcome guard tells you whether a caught value includes a job recovery action. Show that action to the user or use it in an explicit reconciliation flow:

import { isJobUnknownOutcome } from "@relkit/client/react";

export function recoveryAction(error: unknown): string {
  if (!isJobUnknownOutcome(error)) return "Handle the ordinary request error.";
  switch (error.recovery.action) {
    case "retry-with-same-key":
      return `Inspect the receipt for ${error.operationId}; retry only with the same key and request.`;
    case "inspect-native":
      return `Inspect provider state for ${error.operationId} before taking action.`;
    case "unavailable":
      return `Outcome ${error.operationId} is unknown; reconcile manually.`;
  }
}

For ordinary route mutations, use an application-owned status endpoint before resubmitting. The client cannot infer whether a disconnected write reached your backend. For jobs, keep the original operation ID and request digest and follow the provider-certified recovery action.