thedotmack/claude-mem · error · Error

Failed to get processing status: ${res.status}

Error message

Failed to get processing status: ${res.status}

What it means

getProcessingStatus fetches GET /api/processing-status and throws if the response is not 2xx. The worker uses this endpoint to report {isProcessing, queueDepth}. A non-OK status means the worker is up (it answered) but rejected the request — most often a transient 500 from an unhandled handler exception or a 404 if the route isn't registered.

Source

Thrown at scripts/check-pending-queue.ts:85

    const res = await fetchWithTimeout(
      `${WORKER_URL}/api/health`,
      undefined,
      'Health check did not respond',
    );
    return res.ok;
  } catch {
    return false;
  }
}

async function getProcessingStatus(): Promise<ProcessingStatusResponse> {
  const res = await fetchWithTimeout(
    `${WORKER_URL}/api/processing-status`,
    undefined,
    'Failed to get processing status',
  );
  if (!res.ok) {
    throw new Error(`Failed to get processing status: ${res.status}`);
  }
  return res.json() as Promise<ProcessingStatusResponse>;
}

async function triggerProcessing(): Promise<SetProcessingResponse> {
  const res = await fetchWithTimeout(
    `${WORKER_URL}/api/processing`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({})
    },
    'Failed to trigger processing',
  );
  if (!res.ok) {
    throw new Error(`Failed to trigger processing: ${res.status}`);
  }
  return res.json() as Promise<SetProcessingResponse>;

View on GitHub (pinned to d768ba3643)

Solutions

  1. curl -i http://$WORKER_URL/api/processing-status and read the status/body — 404 means the route is missing (rebuild worker), 500 means an internal error (check worker logs).
  2. Rebuild and restart the worker so its routes match this version of the script: npm run build-and-sync / npm run worker:start.
  3. If the body reveals a DB/path error, fix the underlying worker issue (the script is correct).
  4. Retry once after a worker restart — transient 500s on cold start clear up.

Example fix

// before — throws on any non-2xx, message only carries the status code
if (!res.ok) throw new Error(`Failed to get processing status: ${res.status}`);

// after — include the body so the cause is visible without a separate curl
if (!res.ok) {
  const detail = await res.text().catch(() => '<no body>');
  throw new Error(`Failed to get processing status: ${res.status} — ${detail}`);
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Reachability + version check before relying on the endpoint:
async function workerHasProcessingStatus(host: string, port: string): Promise<boolean> {
  try {
    const res = await fetch(`http://${host}:${port}/api/processing-status`);
    return res.ok;
  } catch { return false; }
}

Type guard

function isProcessingStatus(obj: unknown): obj is { isProcessing: boolean; queueDepth: number } {
  return typeof obj === 'object' && obj !== null
    && typeof (obj as any).isProcessing === 'boolean'
    && typeof (obj as any).queueDepth === 'number';
}

Try / catch

try {
  const status = await getProcessingStatus();
  // ...
} catch (err) {
  console.error('Could not read processing status:', err instanceof Error ? err.message : err);
  // hint user to rebuild/restart worker; exit non-zero so CI is honest
  process.exit(1);
}

Prevention

When it happens

Trigger: Worker running an older build without /api/processing-status (404). Handler throws on a malformed internal state (500). Route moved/renamed in a worker version newer than the script expects.

Common situations: Plugin/worker version skew after a partial upgrade. Worker started from a stale build directory. An exception in the worker's processing-status handler (e.g. querying a not-yet-initialised DB).

Related errors

AI-assisted analysis of thedotmack/claude-mem@d768ba3643 (2026-08-12). Data as JSON: /api/errors/019ec6b31a1f3245. Report an issue: GitHub.