Fix research pipeline runtime failures

This commit is contained in:
faligam
2026-09-07 11:16:36 +02:00
parent cf10cd9636
commit a5324d3971
9 changed files with 184 additions and 24 deletions

View File

@@ -5,7 +5,41 @@
---
## Aktueller Stand — 2026-09-06
## Aktueller Stand — 2026-09-07
### Browser-E2E: Such- und Crawler-Pipeline repariert — 2026-09-07
Während des Browser-E2E-Tests traten drei aufeinanderfolgende Backend-Fehler
auf. Alle sind lokal repariert, durch gezielte Tests abgedeckt und mit
`docker compose up -d --build nsct-api` deployed:
1. SearXNG liefert `NormalizedResult`-Pydantic-Objekte. Der Orchestrator
behandelte optionale leere Felder fälschlich als Dictionary und rief `.get()`
auf. Die Ergebnisnormalisierung unterscheidet nun sauber Modelle, Mappings
und ungültige Werte.
2. `AsyncFetcher` konfigurierte bei `httpx.Timeout` connect/read/write, aber
keinen `pool`-Timeout. Der Crawler konnte deshalb nicht initialisiert
werden. `pool` ist nun konfigurierbar über `NSCT_CRAWLER_POOL_TIMEOUT`
(Default 10 Sekunden).
3. Die Budgetierung buchte für jede Ergebnis-URL vor dem Abruf pauschal 500 KB.
Ein Quick-Run mit 22 URLs überschritt so fälschlich das 500-KB-Budget, obwohl
die tatsächlichen Downloads deutlich kleiner waren. Abrufe werden jetzt auf
verbleibende Quellen- und Bytebudgets begrenzt; die Buchung erfolgt nach
tatsächlich abgerufenen Response-Bytes. Budgetobergrenzen sind inklusiv.
Das Quick-Zeitlimit beträgt nun 300 Sekunden (API-Dokumentation angepasst).
Validierung: 63 gezielte Tests (`test_backend_pipeline_repairs.py`,
`test_crawler.py`, `test_search.py`) erfolgreich; Docker-Container und
`/health` erfolgreich. Die komplette REST-Suite startet echte externe
Background-Retries und wurde deshalb nicht abgewartet. Pytest ist lokal in der
ignorierten `.nsct-test-venv` installiert.
Wichtig für den nächsten Browser-Test: Research-Runs werden derzeit nur in
`_research_store` im Arbeitsspeicher gehalten. Jeder API-Neubau/-neustart
entfernt bisherige Run-IDs; die alten Runs liefern danach erwartungsgemäß 404.
Persistente Research-Runs sind ein offener Production-Readiness-Punkt. Vor dem
erneuten Test zuerst eine neue Recherche starten, nicht eine alte Detail-URL
wiederverwenden.
### Laufende Deployments