What causes "response.message (sidecar embed error)" in abhigyanpatwari/GitNexus?

Read the sidecar message for the per-batch failure cause and fix it (reduce batch size, fix inputs, reload model).

response.message (sidecar embed error)

Error message

response.message (sidecar embed error)

What it means

vectorsFromEmbedResponse validates every reply from the sidecar's embed call. If the sidecar responds with type 'error' (it failed to compute embeddings for the batch), the sidecar's message is thrown as an Error. Any other non-'vectors' reply also throws with 'Unexpected sidecar response'.

Solutions

Read the sidecar message for the per-batch failure cause and fix it (reduce batch size, fix inputs, reload model).
Retry the request with a smaller batch to rule out memory pressure during inference.
Confirm sidecar and client versions match; restart the sidecar so it and the client share one protocol.
If the sidecar is repeatedly failing, fall back to the HTTP embedding client.

Example fix

// before: one large batch
const vectors = await sidecarEmbedBatch(allItems);
// after: chunked embed with fallback
const vectors: Float32Array[] = [];
for (const chunk of chunked(allItems, 32)) {
  vectors.push(...await sidecarEmbedBatch(chunk));
}

Defensive patterns

Strategy: try-catch

Try / catch

try {
  vectors = await sidecarEmbedBatch(batch);
} catch (e) {
  if (batch.length > 1) {
    // retry smaller on sidecar embed error (likely memory/size related)
    vectors = (await Promise.all(chunked(batch, Math.ceil(batch.length / 2)).map(sidecarEmbedBatch))).flat();
  } else throw e;
}

Prevention

Keep batch sizes modest (e.g. ≤64) to avoid OOM inside the sidecar.
Sanitize/normalize input text lengths before embedding.
Monitor sidecar health and restart it if repeated embed errors occur.
Keep client and sidecar binaries version-matched.

When it happens

Trigger: sidecarEmbedBatch() sends a batch to the running sidecar; the sidecar replies {type:'error', message} — e.g. batch rejected, model runtime error mid-inference, or the process degraded after init.

Common situations: Sending batches larger than the sidecar can process (OOM during inference), input text the tokenizer cannot handle, model corrupted after load, or protocol mismatch after a CLI/sidecar version skew (old sidecar binary with new client).

Related errors

AI-assisted analysis of abhigyanpatwari/GitNexus@ac9a4e9abd (2026-09-15). Data as JSON: /api/errors/f7e559a3d05ad851. Report an issue: GitHub.

Appendix: source

Thrown at gitnexus/src/core/embeddings/embedding-sidecar-client.ts:407

  if (localUnavailable) throw localUnavailableError();
  if (ready && child) {
    rejectConflictingForceDevice(options?.forceDevice);
    return { device };
  }

  if (!ensureChain) {
    const { signal: _ignored, ...initOptions } = options ?? {};
    ensureChain = spawnAndInit(initOptions).finally(() => {
      ensureChain = null;
    });
  }
  await raceAbort(ensureChain, options?.signal);
  rejectConflictingForceDevice(options?.forceDevice);
  return { device };
};

const vectorsFromEmbedResponse = (response: SidecarResponse): Float32Array[] => {
  if (response.type === 'error') throw new Error(response.message);
  if (response.type !== 'vectors') {
    throw new Error(`Unexpected sidecar response: ${response.type}`);
  }
  return response.vectors.map((row) => Float32Array.from(row));
};

export const sidecarEmbedBatch = async (
  texts: string[],
  options?: { signal?: AbortSignal },
): Promise<Float32Array[]> => {
  if (texts.length === 0) return [];
  options?.signal?.throwIfAborted();
  if (localUnavailable) throw localUnavailableError();

  if (!ready || !child) {
    await ensureEmbeddingSidecar({ signal: options?.signal });
  }

View on GitHub (pinned to ac9a4e9abd)