fix(search): Filter zuverlässiger durch allowTruncate
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 1m16s
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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user