Guard za vypnutým feature flagem = mrtvý kód, který projde review

Příznak

Systém má dvě vrstvy ochrany (např. vnější pre-check na úrovni dispatcheru + vnitřní guard na úrovni runneru). Po záměrném odstranění vnější vrstvy („vnitřní guard to pokryje”) placená/nebezpečná operace proběhne, přestože podle politiky měla být zablokována.

Root cause

Vnitřní guard byl za feature flagem, který byl v produkci vypnutý. Kód guardu existoval, měl testy (které flag v testu zapínaly nebo mockovaly) a prošel code review — ale v produkci se nikdy nevykonal. Jedinou reálnou ochranou byla právě ta vnější vrstva, která flag nečetla. Review ověřilo existenci kódu, nikoli stav flagu v prostředí.

Fix

1. Zapnout flag v cílovém prostředí (ideálně nejdřív na pilotní jednotce), nebo guard z flagu vyjmout, pokud má platit bezpodmínečně.
2. Ověřit živým testem v produkci (ne jen unit testy), že blokační cesta skutečně blokuje: vyvolat stav pod limitem → očekávat fallback/odmítnutí + audit záznam s nulovým nákladem.

Prevence

• Review pravidlo: u každého guardu za feature flagem reviewer MUSÍ ověřit stav flagu ve všech prostředích, kde se na guard spoléhá. „Kód existuje” ≠ „kontrola běží”.
• Před odstraněním redundantní ochranné vrstvy živě dokázat, že zbývající vrstva je aktivní (negative test v produkci/stagingu).
• Fail-safe směr: pokud guard blokuje směrem k bezpečnému fallbacku, zapnutí flagu je nízkorizikové — nejhorší důsledek je zbytečné odmítnutí, ne únik/útrata.

Kategorie

ai-agents / billing / feature flags