fix(search): Filter zuverlässiger durch allowTruncate

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>
2026-04-17 22:33:55 +02:00
parent d3c9bc5619
commit 0992e51a5d
4 changed files with 61 additions and 9 deletions
--- a/src/lib/server/db/migrations/008_thumbnail_cache_drop_unknown.sql
+++ b/src/lib/server/db/migrations/008_thumbnail_cache_drop_unknown.sql
@@ -0,0 +1,7 @@
+-- Bei Migration 007 war `allowTruncate` in fetchText noch nicht implementiert,
+-- weshalb Seiten >512 KB einen Fehler warfen und hasRecipe als NULL (unbekannt)
+-- gespeichert wurde. Diese Einträge würden weitere 30 Tage nicht revalidiert
+-- und Treffer ohne schema.org/Recipe-Markup fälschlich durchlassen. Wir
+-- räumen sie jetzt einmalig ab, damit sie beim nächsten Fetch korrekt
+-- klassifiziert werden. Ein reines Cache-Flush, keine User-Daten betroffen.
+DELETE FROM thumbnail_cache WHERE has_recipe IS NULL;