Files
learnharness/app/api/graph/coverage/extract/route.ts
amosblomqvist e4049e4bf8 Key-presence refusal at every gate: a pinned model is not enough
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.
2026-09-24 22:51:12 +03:00

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