relay credential install was not authoritatively reconciled

Error message

relay credential install was not authoritatively reconciled

What it means

Thrown by assertCommittedInstall (line 296-310) when pairing.getEndpoints' installStatus does not authoritatively confirm the same DeviceCredentialInstalled that provisionRelay just returned. The check requires installStatus to exist, have state==='committed', AND produce a deep-JSON-equal (JSON.stringify) match of the installed result. Any divergence — state 'not-found', undefined, or a field-level difference (e.g., different token, host, or expiry) — is treated as a split-brain between the provision and query RPCs and rejected.

Solutions

On the desktop, ensure provisionRelay and getEndpoints read from the same authoritative install store within one transaction.
Retry pairing — if the install reconciles on a second attempt, the original was a transient race.
Diff the JSON.stringify outputs of installed (from provision) and installStatus.result (from getEndpoints) in a debug build to find the divergent field.
If persistent, clear the desktop's install record and re-pair from scratch.

Defensive patterns

Strategy: validation

Validate before calling

// Before assertCommittedInstall, verify the two payloads reconcile
function installReconciles(
  status: { state: string; result?: unknown } | undefined,
  installed: DeviceCredentialInstalled
): boolean {
  return !!status
    && status.state === 'committed'
    && JSON.stringify(status.result) === JSON.stringify(installed)
}

Type guard

function isUnreconciledInstallError(error: unknown): boolean {
  return error instanceof Error
    && error.message === 'relay credential install was not authoritatively reconciled'
}

Try / catch

try {
  await runPairing(...)
} catch (error) {
  if (isUnreconciledInstallError(error)) {
    // transient race — clear journal and re-pair
    await clearMobileRelayPairingJournal(journalId)
    return startPreProfilePairing(args)
  }
  throw error
}

Prevention

On the desktop, ensure provisionRelay and getEndpoints read from the same authoritative install store.
Treat the first occurrence as a possible transient race — retry once before escalating.
In a debug build, log both JSON.stringify outputs to identify the divergent field.

When it happens

Trigger: provisionRelay returned installed=A, then pairing.getEndpoints returned installStatus={ state:'not-found' } or { state:'committed', result:B } where JSON.stringify(A) !== JSON.stringify(B). Happens if the desktop's provision and query handlers read different stores, if a concurrent reconciliation moved the install between the two calls, or if the schema's optional fields (e.g., a freshly-rotated token) differ.

Common situations: Desktop-side race between credential install and endpoint enumeration; a desktop restart between provisionRelay and getEndpoints that lost the in-memory install; or a schema drift where provisionRelay and getEndpoints serialize DeviceCredentialInstalled with different field sets/defaults.

Related errors

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/0283248aa98d7bad. Report an issue: GitHub.

Appendix: source

Thrown at mobile/src/transport/pre-profile-pairing-coordinator.ts:308

}

function isMethodNotFound(response: RpcResponse): boolean {
  return !response.ok && response.error.code === 'method_not_found'
}

function assertCommittedInstall(
  status:
    | { state: 'not-found' }
    | { state: 'committed'; result: DeviceCredentialInstalled }
    | undefined,
  installed: DeviceCredentialInstalled
): void {
  if (
    !status ||
    status.state !== 'committed' ||
    JSON.stringify(status.result) !== JSON.stringify(installed)
  ) {
    throw new Error('relay credential install was not authoritatively reconciled')
  }
}

function assertActive(isDisposed: () => boolean): void {
  if (isDisposed()) {
    throw new Error('mobile pairing cancelled')
  }
}

View on GitHub (pinned to 1136503c6a)