different-ai/openwork · error · Error

Failed to load GitHub connector instances (${instancesResult

Error message

Failed to load GitHub connector instances (${instancesResult.response.status}).

What it means

The second half of fetchGithubConnections: GET /v1/connector-instances?connectorType=github&status=active&limit=100 returned a non-ok status. Thrown only after the accounts call already passed, so accounts load fine but the per-account repository instances cannot be fetched.

Source

Thrown at ee/apps/den-web/app/(den)/dashboard/_components/integration-data.tsx:280

  const parts = fullName.split("/");
  return parts[parts.length - 1] ?? fullName;
}

async function simulateLatency(ms = 450) {
  return new Promise<void>((resolve) => setTimeout(resolve, ms));
}

async function fetchGithubConnections() {
  const [accountsResult, instancesResult] = await Promise.all([
    requestJson("/v1/connector-accounts?connectorType=github&status=active&limit=100", { method: "GET" }, 15000),
    requestJson("/v1/connector-instances?connectorType=github&status=active&limit=100", { method: "GET" }, 15000),
  ]);

  if (!accountsResult.response.ok) {
    throw new Error(getErrorMessage(accountsResult.payload, `Failed to load GitHub integrations (${accountsResult.response.status}).`));
  }
  if (!instancesResult.response.ok) {
    throw new Error(getErrorMessage(instancesResult.payload, `Failed to load GitHub connector instances (${instancesResult.response.status}).`));
  }

  const accounts = parseGithubConnectorAccounts(accountsResult.payload);
  const instances = parseGithubConnectorInstances(instancesResult.payload);

  return accounts.map<ConnectedIntegration>((account) => ({
    id: account.id,
    provider: "github",
    account: {
      avatarInitial: toAvatarInitial(account.displayName),
      createdByName: account.createdByName,
      id: account.id,
      installationId: account.remoteId ? Number(account.remoteId) : undefined,
      kind: toAccountKind(account.metadata),
      manageUrl: typeof account.metadata?.settingsUrl === "string" ? account.metadata.settingsUrl : null,
      name: account.displayName,
      ownerName: account.externalAccountRef ?? (typeof account.metadata?.accountLogin === "string" ? account.metadata.accountLogin : undefined),
      repositorySelection: account.metadata?.repositorySelection === "selected" ? "selected" : "all",

View on GitHub (pinned to 2b7df46e8a)

Solutions

Read the status code: 401/403 → re-auth/permissions; 404 → deploy/fix the connector-instances service; 5xx → check that service's logs.
Retry the request if transient (the UI query layer can refetch).
Confirm both connector routes are registered on the same API gateway.
Compare server-side logs for the correlation between the accounts (ok) and instances (failed) calls.

Example fix

// before
if (!instancesResult.response.ok) {
  throw new Error(getErrorMessage(instancesResult.payload, `Failed to load GitHub connector instances (${instancesResult.response.status}).`));
}
// after
if (!instancesResult.response.ok) {
  if (instancesResult.response.status >= 500) {
    instancesResult = await requestJson("/v1/connector-instances?connectorType=github&status=active&limit=100", { method: "GET" }, 15000);
  }
  if (!instancesResult.response.ok) throw new Error(getErrorMessage(instancesResult.payload, `Failed to load GitHub connector instances (${instancesResult.response.status}).`));
}

Defensive patterns

Strategy: retry

Validate before calling

const res = await fetch("/v1/connector-instances?connectorType=github&status=active&limit=100", { credentials: "include" });
if (res.status >= 500 || res.status === 429) scheduleRetry();

Type guard

null

Try / catch

try {
  const integrations = await githubConnections();
} catch (e) {
  if (isTransient(e)) retryWithBackoff(githubConnections, 3);
  else setError(e instanceof Error ? e.message : "Failed to load GitHub integrations.");
}

Prevention

Wrap connector fetches in retry-with-backoff for 429/5xx.
Confirm both connector routes are deployed together.
Use TanStack Query retry semantics for transient statuses.
Alert on instances-endpoint errors separately from accounts.

When it happens

Trigger: GET /v1/connector-instances returns 401/403 (auth/role issue), 404 (instances service missing), 429, or 5xx from the connector backend while the accounts endpoint succeeds.

Common situations: Partial deployment where connector-instances route is missing or behind a broken service; transient 5xx in the instances microservice; permissions that allow listing accounts but not instances.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — 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/f4b0f2a5490eb11f. Report an issue: GitHub.