Hlavní větev Transformers přestala vydávat starý soubor z cache za aktuální

Když program načítá model přes knihovnu Transformers, nemusí pokaždé stahovat všechny soubory z Hugging Face Hubu. Společná cache uchovává stažené objekty a vedle nich odkazy na konkrétní revize. Pokud se větev modelu změní, má přibýt nový záznam a starý zůstane k dispozici pro případ, že si o něj aplikace výslovně řekne.

Na systému souborů připojeném jen pro čtení se však tato posloupnost rozbila způsobem, který nebyl na první pohled vidět. Funkce hf_hub_download zjistila, že na Hubu existuje novější revize, ale nový objekt nebo ukazatel na revizi už nedokázala zapsat. Místo jasné chyby pak nadřazená funkce cached_files mohla vrátit dříve uložený soubor.

Novější revize existovala, aplikace dostala starší

Návrh opravy 47852 popisuje konkrétní průběh. Stažení nejprve spojilo jméno větve s novým identifikátorem commitu. Pokus o zápis do adresáře cache potom skončil chybou OSError s číslem 30, tedy EROFS. Ta znamená, že je celý souborový systém jen pro čtení.

Transformers mělo pro chyby při stahování společnou obsluhu. Některé výjimky posílalo dál, jiné vedly k nouzovému použití souboru, který už v cache ležel. EROFS nepatřilo do první skupiny, a proto propadlo až k obnově ze staré cache. Volající program nedostal informaci, že aktualizace selhala.

Problém se v průběžné integraci projektu projevil na souboru chat_template. Bez opravy test podle autorů načetl starou šablonu, s opravou už prošel s novou. To zároveň vymezuje doložený rozsah: návrh mluví o vzácném nastavení, používaném hlavně ve vlastní průběžné integraci projektu. Netvrdí, že se chyba běžně projevovala u všech uživatelů Transformers.

Python rozlišuje zákaz zápisu dvěma výjimkami

Příčinou nebyla samotná cache, ale rozdíl mezi dvěma podobnými zákazy zápisu. Když uživatel nemá k zapisovatelnému adresáři oprávnění, operační systém vrátí EACCES s číslem 13. Python tuto chybu mapuje na zvláštní třídu PermissionError a původní podmínka v Transformers ji zachytila.

Souborový systém připojený celý jen pro čtení vrací EROFS s číslem 30. Dokumentace Pythonu ho vede jako samostatný systémový symbol, ne jako chybu mapovanou na PermissionError. V programu proto zůstane obecným OSError. Kontrola isinstance(e, PermissionError) tak pokryla zákaz podle práv k adresáři, ale ne zákaz daný režimem celého připojeného systému.

Režim jen pro čtení je běžné bezpečnostní opatření

Nejde přitom o nesmyslné nastavení. Bezpečnostní checklist Kubernetes doporučuje u kontejneru nastavit readOnlyRootFilesystem: true. Aplikace pak nemůže zapisovat do kořenového systému kontejneru; zapisovatelná data musí správce umístit do samostatného svazku.

Cache Hugging Face má podle dokumentace huggingface_hub výchozí adresář ~/.cache/huggingface/hub. Umístění lze změnit parametrem cache_dir nebo proměnnými HF_HOME a HF_HUB_CACHE. Samotný kořenový systém jen pro čtení tedy nemusí znamenat cache jen pro čtení; záleží na tom, kam je cache nasměrovaná a jaké svazky kontejner dostal.

Oprava chybu ukáže, cestu sama nepřepne

Commit sloučený 9. srpna přidává přesnou kontrolu isinstance(e, OSError) and e.errno == errno.EROFS. Když sedí, výjimku znovu vyvolá dřív, než se kód dostane k nouzovému použití starého souboru. Aplikace tak může selhání přiznat nebo opakovat stažení do zapisovatelného adresáře.

Změna sama žádnou náhradní cestu nevybírá. V průběžné integraci Transformers ji obstarává zvláštní obal, který po chybě zkusí dočasnou cache. Pro ostatní volající je výsledkem především jiná smlouva: místo souboru, který vypadá aktuálně, dostanou chybu a musí rozhodnout, co s ní.

Oprava je zatím v hlavní větvi repozitáře. Z commitu neplyne číslo balíčku, ve kterém se dostane k uživatelům, a proto ho nelze vydávat za nové stabilní vydání. Provozovatel může do té doby ověřit dvě věci bez odhadu: zda jeho cache opravdu leží na systému jen pro čtení a zda načítá pevně určenou revizi, nebo pokaždé žádá nejnovější stav větve.