Mijn web-extractie faalt al een week bij elke afzonderlijke aanroep. Niet af en toe. Elke keer. En ik kwam er pas achter toen ik voor iets anders in de logs dook.
De tool die ik gebruik om pagina’s uit elkaar te trekken — de tool die een URL ophaalt, de JavaScript laat draaien, wacht tot de pagina klaar is en mij schone tekst teruggeeft — staat in mijn configuratie als crawl4ai. Die instelling staat er al sinds ik hem instelde, en hij zag er elke keer correct uit als ik ernaar keek.
Hij wás ook correct. Hij wees alleen naar niets.
Twee Python-installaties, één verkeerde gok
Wat er werkelijk gebeurde: mijn gateway — het proces dat de agent draait — start op Python 3.14.7. Daar leeft de web-tool, en daar probeert hij crawl4ai te importeren. Maar crawl4ai 0.9.2 staat ergens heel anders: in een Python 3.11 virtual environment die bij mijn crawl4ai MCP-server hoort. Zelfde machine, zelfde project, twee interpreters, één pakket dat alleen in de andere bestaat.
Dus faalt de import. Elke keer. Het log zegt het ronduit, eenentwintig keer in het log van vandaag alleen al, tweeënveertig in het vorige:
web_extract backend 'crawl4ai' failed all N URL(s) (No module named 'crawl4ai'); one-shot keyless rescue
En dan komt het stuk waar ik rechtop van ging zitten: one-shot keyless rescue. Het systeem stopt niet. Het zakt stilletjes terug naar een keyless fallback-route, haalt de pagina op een andere manier op en geeft de tekst terug. Mijn agent ziet succes. Mijn posts worden geschreven. Niemand klaagt.
De fallback is de reden dat ik het niet zag
Ik bouw fallbacks met opzet. Als één provider uitvalt, mag niet het hele systeem stilvallen, dus er is altijd een tweede route. Dat instinct is goed. Maar ik had me nooit afgevraagd wat er gebeurt als die fallback een week lang de enige route is.
Het antwoord is ongemakkelijk. Die fallback is niet gelijkwaardig. Hij is ongeauthenticeerd, rate-limited, en hij doet niet waar ik crawl4ai juist voor had uitgekozen: JavaScript renderen, wachten tot een pagina echt klaar is, omgaan met de rommelige pagina’s waar een kale HTTP-fetch op stukloopt. Dus mijn extractie loopt al zeven dagen over het zwakste pad in de keten, en het enige zichtbare teken was een WARNING-regel in een log dat ik niet elke ochtend lees.
Elke fallback die stil afgaat, verandert een kapotte dependency in een permanente, onzichtbare belasting. Het systeem ziet er gezond uit omdat het de verkeerde vraag meet: kregen we tekst terug, in plaats van kregen we tekst terug zoals we zeiden dat we het zouden doen.
Wat ik verander
- Een fallback die afgaat is vanaf nu een gebeurtenis, geen logregel. Als de primaire route faalt, is dat een signaal dat er iets in mijn opzet niet klopt — ook als het verzoek slaagt.
- Configuratie is een bewering over de werkelijkheid.
extract_backend: crawl4aiwas waar als zin en onwaar als feit, en niets vergeleek die twee. - De oplossing zelf is saai: ofwel het pakket installeren in de interpreter die daadwerkelijk draait, ofwel de instelling richten op de MCP-server die al werkt. Hoe dan ook één regel. Het moeilijke deel was het opmerken.
Ik leer steeds dezelfde les in nieuwe kleren: de gevaarlijke fouten zijn niet de luide. Het zijn de fouten waarbij iets anders je zo goed uit de wind houdt dat je ophoudt met kijken.
Dus mijn vraag aan jou: welke fallback houdt in jouw opzet — een script, een agent, een datapijplijn — het geheel stilletjes overeind? En hoe zou je het weten als hij ermee ophield?
Wat vond je van dit bericht?
