PydanticAI 2.19 sprístupňuje údaje z HTTP chýb a spevňuje rušenie behov agentov

PydanticAI vydal verziu 2.19.0, ktorá je rozsahom malá, no zasahuje dve prevádzkovo citlivé oblasti agentických systémov: rozhodovanie po chybe modelového API a spoľahlivé ukončenie rozbehnutého agenta. Trieda ModelHTTPError po novom nesie HTTP hlavičky aj hodnotu retry_after, pričom knižnica tieto údaje dopĺňa zo všetkých podporovaných poskytovateľských SDK. Pre aplikáciu to znamená, že nemusí hádať, kedy má požiadavku zopakovať, ani obchádzať abstrakciu knižnice, aby sa dostala k metadátam odpovede.

Zmena je dôležitá najmä pri limitoch požiadaviek, dočasnom preťažení služby a riadenom prepínaní medzi modelmi. Keď poskytovateľ vráti napríklad stav 429 spolu s údajom Retry-After, orchestrátor môže rešpektovať odporúčané čakanie namiesto pevne nastaveného intervalu. Tým sa znižuje riziko, že opakované požiadavky ešte viac zaťažia službu alebo spotrebujú rozpočet na neúspešné volania. Hlavičky zároveň môžu obsahovať identifikátor požiadavky či informácie užitočné pri podpore a audite incidentu.

Pre produkčné nasadenie však samotné sprístupnenie údajov nestačí. Vývojári musia určiť, ktoré HTTP chyby sú dočasné, koľko opakovaní je prijateľných a kedy sa má použiť iný model alebo poskytovateľ. Hodnotu retry_after treba kombinovať s exponenciálnym oneskorením, náhodným rozptylom a celkovým časovým rozpočtom úlohy. Inak môže agent síce korektne čakať, ale prekročí čas odozvy služby alebo zostane blokovaný dlhšie, než povoľuje používateľský proces.

Druhá oprava znovu uplatňuje externé zrušenie na hraniciach jednotlivých krokov behu. Agentický proces sa skladá z modelových volaní, nástrojov a prechodov medzi stavmi; požiadavka na zrušenie preto môže prísť práve v okamihu, keď sa dokončuje jeden krok a začína ďalší. Ak sa tento signál cestou stratí alebo pohltí, systém môže pokračovať v používaní nástrojov aj po odpojení klienta, vypršaní limitu či manuálnom zastavení operátorom.

Oprava má praktický význam pre webové služby, dávkové úlohy aj agentov, ktorí pracujú s nákladnými alebo stavovými nástrojmi. Zrušenie by malo zastaviť ďalšiu prácu, ale zároveň nesmie poškodiť rozpracované údaje. Aplikácia preto potrebuje idempotentné nástroje, bezpečné hranice transakcií a upratovanie zdrojov vo vetve pre zrušenie. Knižnica spevňuje prenos signálu; zodpovednosť za konzistentný stav databázy alebo externej služby zostáva na integrátorovi.

Verzia 2.19.0 tiež mení povolený rozsah závislosti FastMCP na verzie nižšie než 4. Nejde o novú používateľskú funkciu, ale o dôležitý signál pre tímy, ktoré kombinujú PydanticAI s nástrojmi cez Model Context Protocol. Horná hranica chráni pred automatickým prechodom na nekompatibilnú hlavnú verziu. Pri aktualizácii treba preto skontrolovať zámkový súbor závislostí a overiť, či iná časť aplikácie nevyžaduje FastMCP 4.

Release nadväzuje na verziu 2.18.0 a nemení základný spôsob definovania agentov. Riziko migrácie je preto menšie než pri veľkej verzii, no prevádzkové správanie sa môže zmeniť tam, kde aplikácia zachytáva ModelHTTPError alebo testuje rušenie úloh. Dobré regresné testy majú simulovať stav 429 s hlavičkou Retry-After, chybu 5xx bez tejto hlavičky a zrušenie počas modelového volania aj tesne pred spustením nástroja.

Sprístupnené hlavičky by sa nemali bez filtra zapisovať do používateľských odpovedí ani do verejných logov. Niektoré integračné metadáta môžu obsahovať interné identifikátory alebo informácie, ktoré majú zostať iba v telemetrii. Bezpečný návrh vyberie povolené polia, oddelí diagnostický záznam od verejnej chyby a zachová korelačný identifikátor pre podporu bez toho, aby odhalil autentifikačné údaje.

Pre tímy s viacerými poskytovateľmi je prínosom jednotná chyba nad rozdielnymi SDK. Aplikačná vrstva môže mať jednu politiku pre opakovanie, meranie dostupnosti a prechod na záložný model. Stále však treba otestovať reálne odpovede každého poskytovateľa, pretože rovnaký stavový kód nemusí znamenať rovnakú príčinu a údaj o čakaní nemusí byť vždy prítomný alebo použiteľný ako celé číslo sekúnd.

PydanticAI 2.19.0 tak neprináša veľký nový modul, ale odstraňuje dve časté zdroje nepredvídateľnosti. Lepšie metadáta chýb umožnia disciplinovanejšie riadenie prevádzky a oprava rušenia obmedzí prácu, ktorá pokračovala po strate záujmu klienta. Najväčší úžitok získajú tímy, ktoré zmenu doplnia testami chaosu, jasným časovým rozpočtom a meraním počtu opakovaní, zrušených krokov a nedokončených nástrojových operácií.