Fix research pipeline runtime failures
This commit is contained in:
36
HANDOFF.md
36
HANDOFF.md
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user