can1357/oh-my-pi · error · Error

response.errorMessage ?? "auto-repair completion failed"

Error message

response.errorMessage ?? "auto-repair completion failed"

What it means

In auto-repair's `complete` callback, when the LLM completion call returns stopReason 'error', the raw provider error message is thrown (or a generic fallback if none). This aborts the parse-regression repair flow, which needs a model completion to synthesize a corrected patch.

Source

Thrown at packages/coding-agent/src/edit/auto-repair.ts:328

	const timeout = AbortSignal.timeout(REPAIR_TIMEOUT_MS);
	const signal = options.signal ? AbortSignal.any([options.signal, timeout]) : timeout;
	const complete = async (builtPrompt: string): Promise<string> => {
		const response = await retryTransientCompletion(
			() =>
				completeSimple(
					model,
					{ messages: [{ role: "user", content: builtPrompt, timestamp: Date.now() }] },
					{
						apiKey: registry.resolver(model, sessionId),
						maxTokens: COMPLETION_MAX_TOKENS,
						disableReasoning: true,
						signal,
					},
				),
			{ signal },
		);
		if (response.stopReason === "error") {
			throw new Error(response.errorMessage ?? "auto-repair completion failed");
		}
		return response.content.map(block => (block.type === "text" ? block.text : "")).join("");
	};

	const repair = await repairParseRegression({ ...snapshot, next: current }, complete);
	if (!repair) return undefined;

	await writethrough(snapshot.path, repair.content, options.signal, Bun.file(snapshot.path));
	invalidateFsScanAfterWrite(snapshot.path);
	logger.debug("Edit auto-repair applied", {
		path: snapshot.path,
		attempts: repair.attempts,
		regionLines: repair.region.bEnd - repair.region.bStart,
	});
	const diffResult = generateDiffString(current, repair.content, undefined, { path: snapshot.path });
	return { diff: diffResult.diff, model: `${model.provider}/${model.id}`, attempts: repair.attempts };
}

View on GitHub (pinned to 9690622007)

Solutions

Check the underlying errorMessage (rate limit, auth, network) and fix that root cause first
Verify provider credentials/API key validity and billing status
Retry the apply/repair after backoff if the provider error is transient
Reduce context/prompt size if the error is context-overflow; or skip auto-repair and apply the patch manually

Example fix

// before
const repaired = await autoRepair(snapshot); // throws on provider error
// after
let repaired;
try {
	repaired = await autoRepair(snapshot);
} catch (err) {
	logger.warn('auto-repair unavailable', { err });
	repaired = undefined; // fall back to surfacing the original parse error
}

Defensive patterns

Strategy: try-catch

Try / catch

try {
	const repaired = await autoRepair(snapshot);
} catch (err) {
	logger.warn('auto-repair completion failed', { err });
	// fall back to reporting the original parse failure unrepaired
}

Prevention

Check API key/billing health before long repair flows
Handle provider stopReason 'error' upstream and retry with backoff
Cap context growth so repair completions stay within limits

When it happens

Trigger: Calling complete (via repairParseRegression, invoked from the `candidate` path in auto-repair) when the underlying provider request fails: stopReason === 'error' with response.errorMessage set (e.g. rate limit, auth failure, context overflow) or undefined.

Common situations: API key expired/invalid during a long session; provider rate limits hit after a failed apply triggered repair; network outage; model returned an error stop reason due to oversized context after accumulating patch history.

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/442eb31c6fdb1999. Report an issue: GitHub.