Owner-diagnosed: the turn gate checked only model coordinates, so a pinned slot whose provider key was deleted passed the gate and died mid-stream masked to 'An error occurred.' The key is now gated where the model is — by what would RUN (env-first keyValue truth, so an env-shadowed key passes). - core/settings.ts: the provider_key_missing envelope family (code, provider, slots, human line naming the provider from AUTH_PROVIDER_KEYS labels) + ProviderKeyMissingError + isProviderKeyRefusal matcher. - chat-handler turn gate: refuses 503 before beginTurn when the resolved conversation's provider key is gone (slots: [strong]). - Job runner: same check via an injected dep (agent layer cannot read the key store) — a keyless engine refuses the spawn through the existing failure-shape convention, no phantom run. - Extraction pipeline: refuseIfStagesUnready refuses BEFORE any batch (first offender: extractor before auditor); the trigger skips info- level, /api/graph/import surfaces the 503 envelope per file. - Tests: 8 new pins (turn gate both ways, runner refusal, pipeline first-offender + pass-through, envelope factory, matcher); the three turn-driving suites seed OPENROUTER_API_KEY like any real setup. - Doc fix: stale EXTRACTION.chunkTokens comment in the manual-extract route (left over from eed4b4e). Known residual (pre-existing, flagged for master): the manual extract route logs BOTH config refusals as console.error (fire-and-forget path); the coverage ledger keeps everything uncovered either way.
37 lines
1.7 KiB
TypeScript
37 lines
1.7 KiB
TypeScript
/**
|
|
* POST /api/graph/coverage/extract — the manual extraction affordance
|
|
* (vision-extraction-coverage.md): run the pipeline over ONE session's
|
|
* uncovered content, whatever its size — the user's answer to an aborted
|
|
* run, a pipeline error, or a session that went dormant under the chunk
|
|
* budget. The pipeline itself batches under the graph.extractionChunkTokens setting (extraction-UX redesign,
|
|
* 2026-09-24) and
|
|
* checkpoints coverage per merged batch, so this is the same run the
|
|
* trigger fires, just user-initiated. 409 while a run is already in
|
|
* flight (the dock is the source of truth for that); failures are logged
|
|
* by the pipeline and leave coverage untouched — the button stays honest.
|
|
*/
|
|
import { extraction, extractionStatuses } from "@/src/server";
|
|
|
|
export const dynamic = "force-dynamic";
|
|
|
|
export async function POST(request: Request) {
|
|
let body: unknown;
|
|
try {
|
|
body = await request.json();
|
|
} catch {
|
|
return Response.json({ error: "Invalid JSON body" }, { status: 400 });
|
|
}
|
|
const chatId = (body as { chatId?: unknown }).chatId;
|
|
if (typeof chatId !== "string" || chatId === "") {
|
|
return Response.json({ error: 'Body must be {chatId: string}' }, { status: 400 });
|
|
}
|
|
if (extractionStatuses().some((run) => run.kind === "chat" && run.chatId === chatId)) {
|
|
return Response.json({ error: "An extraction run is already in flight for this session" }, { status: 409 });
|
|
}
|
|
// Fire-and-forget, like the trigger: the dock + the coverage panel's
|
|
// running flags track progress; the promise never blocks the response.
|
|
void extraction.runExtraction(chatId).catch((err: unknown) => {
|
|
console.error(`[chat ${chatId}] manual extraction failed:`, err);
|
|
});
|
|
return Response.json({ started: true }, { status: 202 });
|
|
} |