different-ai/openwork · error

Invalid cloud provider sync status.

Error message

Invalid cloud provider sync status.

What it means

After confirming a `status` field exists, parseCloudProviderSyncRun checks it against the allowed values: applied, noop, failed, no_session. Any other status string throws this error, protecting callers from handling an unrecognized sync outcome.

Source

Thrown at apps/app/src/app/lib/openwork-server.ts:73

  /** Machine-readable skip reason, e.g. "missing_credentials". */
  reason: string;
};

export type OpenworkCloudProviderSyncStatus = {
  hasSession: boolean;
  lastRun: { at: string | number; status: OpenworkCloudProviderSyncRun["status"]; message?: string } | null;
  providers: CloudImportedProvider[];
  /** A managed engine reload is still owed: materialized providers are not served yet. */
  reloadPending: boolean;
  /** Den-granted providers the server sync skipped, each with a reason. */
  skippedProviders: OpenworkCloudProviderSyncSkippedProvider[];
};

function parseCloudProviderSyncRun(value: unknown): OpenworkCloudProviderSyncRun {
  if (!value || typeof value !== "object" || !("status" in value)) throw new Error("Invalid cloud provider sync response.");
  const status = value.status;
  if (status !== "applied" && status !== "noop" && status !== "failed" && status !== "no_session") {
    throw new Error("Invalid cloud provider sync status.");
  }
  const message = "message" in value && typeof value.message === "string" ? value.message : undefined;
  return { status, message };
}

function parseCloudImportedProvider(value: unknown): CloudImportedProvider | null {
  if (!value || typeof value !== "object") return null;
  if (
    !("cloudProviderId" in value) || typeof value.cloudProviderId !== "string" ||
    !("providerId" in value) || typeof value.providerId !== "string" ||
    !("sourceProviderId" in value) || typeof value.sourceProviderId !== "string" ||
    !("name" in value) || typeof value.name !== "string" ||
    !("modelIds" in value) || !Array.isArray(value.modelIds) || !value.modelIds.every((item) => typeof item === "string")
  ) return null;
  return {
    cloudProviderId: value.cloudProviderId,
    providerId: value.providerId,
    sourceProviderId: value.sourceProviderId,

View on GitHub (pinned to 2b7df46e8a)

Solutions

  1. Log the unexpected status value to identify exactly what the server sent.
  2. Update the client's allowed-status union to include the new server status and handle it.
  3. Align client and server versions so enums match.
  4. Verify the request hits the sync run endpoint, not another route.

Example fix

// before
if (status !== "applied" && status !== "noop" && status !== "failed" && status !== "no_session") {
  throw new Error("Invalid cloud provider sync status.");
}
// after: tolerate known-but-unhandled statuses explicitly
const KNOWN = ["applied", "noop", "failed", "no_session"] as const;
if (!KNOWN.includes(status)) throw new Error(`Invalid cloud provider sync status: ${String(status)}`);
Defensive patterns

Strategy: validation

Validate before calling

const body = await res.json();
if (body && typeof body === "object" && "status" in body) {
  const KNOWN = ["applied", "noop", "failed", "no_session"];
  if (!KNOWN.includes(body.status)) console.warn("Server returned unknown sync status:", body.status);
}

Type guard

function isKnownSyncStatus(s: unknown): s is "applied" | "noop" | "failed" | "no_session" {
  return s === "applied" || s === "noop" || s === "failed" || s === "no_session";
}

Try / catch

try {
  const run = await client.cloud.providerSync.run();
} catch (err) {
  if (err instanceof Error && err.message.includes("Invalid cloud provider sync status")) {
    // enum skew: pin client to matching server version and report the raw status
    reportClientServerVersionSkew(err);
  } else throw err;
}

Prevention

When it happens

Trigger: The sync run response contains a `status` value outside the known set — a server upgrade introduced a new status (e.g. "partial"), or a localized/error payload coincidentally includes a status string.

Common situations: Client and Den server version skew after a server-side enum addition, mock/test server returning statuses the client doesn't know, or a different endpoint's payload being parsed by mistake.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


AI-assisted analysis of different-ai/openwork@2b7df46e8a (2026-09-01). Data as JSON: /api/errors/7a6dc899fa46518c. Report an issue: GitHub.