thedotmack/claude-mem · error · Error

Failed to trigger processing: ${res.status}

Error message

Failed to trigger processing: ${res.status}

What it means

triggerProcessing POSTs an empty body to /api/processing and throws on a non-2xx response. The endpoint starts/reports an asynchronous processing run. A non-OK status means the worker accepted the connection but refused to start processing — typically 409 when already processing, 500 on an internal error, or 404 if the route is absent.

Source

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

  );
  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>;
}

async function prompt(question: string): Promise<string> {
  if (!process.stdin.isTTY) {
    console.log(question + '(no TTY, use --process flag for non-interactive mode)');
    return 'n';
  }

  return new Promise((resolve) => {
    process.stdout.write(question);
    process.stdin.setRawMode(false);
    process.stdin.resume();
    process.stdin.once('data', (data) => {
      process.stdin.pause();
      resolve(data.toString().trim());
    });

View on GitHub (pinned to d768ba3643)

Solutions

  1. Run GET /api/processing-status first (the script does) — if isProcessing is already true, you don't need to POST.
  2. curl -i -X POST http://$WORKER_URL/api/processing -H 'Content-Type: application/json' -d '{}' and read the status/body to distinguish 404/409/500.
  3. Rebuild/restart the worker if the route is missing (404).
  4. If 500, inspect worker logs for the kickoff-time exception (often a DB or Chroma init problem).

Example fix

// before — only status code in the message
if (!res.ok) throw new Error(`Failed to trigger processing: ${res.status}`);

// after — surface the response body and treat 409 (already processing) as non-fatal
if (!res.ok) {
  const detail = await res.text().catch(() => '<no body>');
  if (res.status === 409) { console.log('Worker already processing — nothing to do.'); return; }
  throw new Error(`Failed to trigger processing: ${res.status} — ${detail}`);
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Only trigger when not already processing, to avoid 409-style failures:
const status = await getProcessingStatus();
if (status.isProcessing || status.queueDepth === 0) {
  console.log('Nothing to do:', status);
  process.exit(0);
}

Type guard

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

Try / catch

try {
  const result = await triggerProcessing();
  console.log('Triggered:', result);
} catch (err) {
  const msg = err instanceof Error ? err.message : String(err);
  if (msg.includes(' 409')) { console.log('Already processing — no action taken.'); process.exit(0); }
  console.error('Failed to trigger processing:', msg);
  process.exit(1);
}

Prevention

When it happens

Trigger: POSTing /api/processing while the worker is already processing (possible 409). Worker build predates the route (404). Handler exception during processing kickoff (500). Empty JSON body rejected by stricter validation (400).

Common situations: Running the script twice in quick succession. Plugin/worker version skew. Worker mid-restart when the POST lands.

Related errors


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