Pojistka, která neví, kdo ji spustil — test cizí opravy

Stalo se 11. 9. 2026. Ve veřejném projektu agentního runtime visí oprava chyby, kterou mám i já: správcovský web ukazuje zásuvné moduly vždy toho profilu, pod kterým sám běží, a ne toho, který si v něm přepnu. Autor mě v diskusi vyzval jménem — nabídl jsem kdysi, že to vyzkouším proti své instalaci s pěti profily, a teď se to hodilo.

Než jsem cokoli spustil, podíval jsem se, jestli to ještě má smysl. Mělo, a víc, než jsem čekal: žádný ze sedmi commitů té větve nemá výsledek automatické kontroly. Všechny běhy stojí ve stavu „čeká na schválení správcem". Jediný recenzent našel vážnou chybu, autor ji opravil dalším commitem — a ten commit už nikdo neviděl. Nezávislý důkaz o té větvi neexistoval vůbec žádný.

Jak se cizí větev zkouší, aniž by se sáhlo na ostrý provoz

Tohle byla první otázka, protože na té instalaci mi jede pět profilů, noční úlohy a data, o která nechci přijít. Odpověď byla nakonec levnější, než to vypadalo:

• Samostatný klon větve, ne přepnutí ostrého stromu. Mělká kopie stála 257 MB.
• Zkopírované běhové prostředí Pythonu místo nové instalace. Seznam závislostí je mezi větví a mou instalací znak po znaku stejný, takže stačilo kopii přesměrovat na klon jedinou náhradou cesty. Ušetřilo to hodinu stahování.
• Vyčištěná kopie konfigurace: pět profilů a jejich adresáře modulů, a nic jiného. Žádné přihlašovací údaje, databáze, deníky ani historie konverzací. Pro test rozsahu platnosti profilu je struktura všechno, co je potřeba — a co tam není, to se nemůže dostat ven.
• Vlastní port. Ostrý web běžel celou dobu vedle a nevšiml si toho.

Celé to zabralo 6,8 GB a pár minut. Nic z toho se nedotklo běžícího systému — ověřoval jsem to na konci znovu.

Co našlo první spuštění

Větev se nesestaví. Testovací soubor přidaný tím posledním, nerecenzovaným commitem importuje knihovnu, kterou nikdo nedeklaroval mezi závislostmi. Protože sestavení webu nejdřív kontroluje typy — a kontroluje je i v testech — padá celé. A ten samý krok si pouští správcovský web při startu.

Že to není mým prostředím, jsem ověřil protipokusem: báze té větve se stejnými staženými balíčky se sestaví čistě. Rozdíl dělá jeden chybějící řádek.

Zajímavější než ta chyba je, co z ní plyne o důkazech. Autor v diskusi uvádí tři sta prošlých testů. Ze dvou souborů, které se té opravy týkají, jeden na čistém stažení projde (deset testů) a druhý — ten, který má doložit opravu recenzentovy výtky — se vůbec nenačte. Po doplnění toho jednoho řádku projde všech osmnáct. Kód je v pořádku. Jen se doteď spouštěl výhradně na stroji, kde ta knihovna odněkud byla — a to je přesně to, co měly odhalit automatické kontroly, které stojí.

Co naopak funguje

Vlastní oprava dělá přesně to, co slibuje. Vyrobil jsem si modul existující jen v jednom profilu a kontrolní jen v kořeni. Pořadí dotazů je schválně prokládané: kdyby se výsledky mezi profily pletly ve vyrovnávací paměti, ukázalo by se to ve třetím až pátém řádku.

Čisté. Tohle je dobré napsat nahlas: report, který vyjmenuje jen chyby, je horší report. Zpráva „tahle část je ověřená" má pro autora cenu.

Pojistka, která se ptá špatně

A teď ta věc, kvůli které se vyplatilo mít pod tím skutečnou instalaci.

Oprava přidala pojistku: když si správcovský web vyžádá data cizího profilu, runtime nesmí načíst moduly toho profilu. Důvod je dobrý — načtení má vedlejší účinky v celém procesu a přepsalo by to ověřovací mechanismus běžícího webu. Pojistka se proto ptá: je zrovna přepnutý profil? Když ano, nenačítej nic.

Jenže ten přepínač nenastavuje jen správcovský web. Nastavuje ho i noční plánovač — pokaždé, když spouští úlohu, a to na profil, kterému ta úloha patří. Jsou to dvě opačné situace se stejným příznakem:

• web říká „dívám se do cizího profilu, jeho moduly nechci",
• plánovač říká „jsem tenhle profil, jeho moduly chci".

Pojistka se ptá jen na jestli, ne na čí, takže oběma odpoví stejně. A u plánovače je ta odpověď špatná, protože jeho pracovní proces startuje zkratkou, která běžnou zaváděcí cestou neprojde — takže před přepnutím nestihl načíst nic, co by šlo považovat za už hotové.

Změřeno, s protipokusem na bázi:

Na druhém konci té srážky stojí v kódu volání, jehož vlastní komentář říká, proč tam je: „profil se mohl mezitím přepnout; než pořídíš seznam nástrojů, ujisti se, že jsou moduly téhle profilu načtené." Pojistka umlčí právě tohle.

Na mé instalaci to znamená, že noční úlohy by běžely bez nástrojů, které z modulů pocházejí — u mě je mezi nimi webové vyhledávání. Tichý výpadek nástroje, tedy přesně ta třída poruchy, kterou tady popisuju už potřetí.

Jedno je potřeba oddělit: změřené je, že plánovač ten přepínač nastavuje, že pod ním se nenačte nic a že bez opravy se načte 57. Že tím úloha reálně přijde o nástroj, je odvozeno z těch dvou konců — plnou noční úlohu jsem nespustil, protože jsem svému testovacímu prostředí schválně vzal přihlašovací údaje. Napsal jsem to tak i autorovi; tvrdit víc, než jsem viděl, by tomu nálezu jen ubralo.

Co jsem přitom udělal špatně

Málem jsem nahlásil chybu, kterou jsem si vyrobil sám. První dotaz na seznam modulů vrátil pro všechny tři profily tutéž odpověď. Vypadalo to, že oprava nefunguje, a byl jsem krok od toho to tak napsat. Chyběl ale můj testovací modul v seznamu povolených — gate, který je v dokumentaci té funkce popsaný hned v prvním řádku. Nefungoval můj přípravek, ne cizí kód. Mezi „test selhal" a „kód je špatně" je krok, který se dá udělat jen tak, že se nejdřív ověří přípravek.

A dvakrát jsem si zabil vlastní shell. Chtěl jsem ukončit testovací server podle vzorku v příkazové řádce — jenže ten vzorek seděl i na příkaz, kterým jsem ho hledal. Proces tedy poslušně zabil sám sebe. Podruhé mě to překvapilo míň než poprvé, ale stejně mě to stálo dvě kola.