fix(search): Filter zuverlässiger durch allowTruncate
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 1m16s

Vorher warf fetchText einen Fehler, sobald eine Seite >512 KB war —
bei modernen Rezeptseiten (eingebettete Bundles, base64-Bilder) läuft
das praktisch immer voll. Der Catch-Block hat dann hasRecipe auf NULL
gelassen, und der Treffer ging ungefiltert durch.

Neue FetchOptions.allowTruncate: true → wir bekommen die ersten 512 KB
(das reicht für <head> mit og:image und JSON-LD) statt eines Throws.
Timeout auf 8s erhöht, weil der Pi manchmal langsamer ist.

Migration 008 räumt alte NULL-has_recipe-Einträge aus dem Cache, damit
sie beim nächsten Search frisch klassifiziert werden statt weitere
30 Tage falsch gecached zu bleiben.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
hsiegeln
2026-04-17 22:33:55 +02:00
parent d3c9bc5619
commit 0992e51a5d
4 changed files with 61 additions and 9 deletions

View File

@@ -223,7 +223,16 @@ async function enrichPageMeta(
if (cached) return cached;
let meta: PageMeta = { image: null, hasRecipe: null };
try {
const html = await fetchText(url, { timeoutMs: 4_000, maxBytes: 512 * 1024 });
// allowTruncate: moderne Rezeptseiten sind oft >1 MB (eingebettete
// Bundles, base64-Bilder). Das og:image und JSON-LD steht praktisch
// immer im <head>, was locker in die ersten 512 KB passt. Früher
// warf fetchText auf Überschreitung und hasRecipe blieb NULL, sodass
// Nicht-Rezept-Seiten fälschlich durchgingen.
const html = await fetchText(url, {
timeoutMs: 8_000,
maxBytes: 512 * 1024,
allowTruncate: true
});
meta = {
image: extractPageImage(html, url),
hasRecipe: hasRecipeJsonLd(html) ? 1 : 0