[Hoch] Feature-Flags wirkungslos: Flagception 6 wertet nur PHP-Attribute aus, Controller nutzen Docblock-Annotationen

[maltehuebner]

Problem

Die Controller „schützen" Routen mit Docblock-Annotationen:

// src/Controller/AnalysisController.php:16-18 (Klasse), 21-23, 43-45, 61-63
/**
 * @Feature("analysis_komfortofen")
 */
public function komfortofenAction(...)

ebenso src/Controller/StationController.php:57-59 (@Feature("station_history")).

Installiert ist flagception/flagception-bundle 6.1, dessen einziger Controller-Listener vendor/flagception/flagception-bundle/src/Listener/AttributeSubscriber.php ausschließlich native PHP-Attribute liest ($object->getAttributes(Feature::class, ReflectionAttribute::IS_INSTANCEOF)). Einen Annotation-Reader gibt es nicht mehr, doctrine/annotations ist nicht installiert. Alle fünf @Feature-Annotationen sind damit stillschweigend wirkungslos.

Beweis

config/packages/flagception.yaml setzt analysis_fireworks: false, analysis_komfortofen: false, station_history: false → die Routen müssten 404 liefern. Tatsächlich antworten /komfortofen und /analysis/silvester mit 500 (Controller wird ausgeführt und crasht, siehe Elastica-Issue) statt 404 — der Flag-Check findet nie statt.

Zusätzlicher Flag-Namens-Mismatch

• config/packages/flagception.yaml definiert analysis_fireworks_corona: true; der Menülink wird über feature('analysis_fireworks_corona') eingeblendet (templates/Includes/menu.html.twig:74-80).
• AnalysisController::coronaFireworksAction (Z. 61–63) ist aber mit @Feature("analysis_fireworks") (= false) annotiert.
• Konsequenz: Bei einer naiven 1:1-Konvertierung zu Attributen würde die einzige verlinkte und funktionierende Analyse-Seite (/analysis/corona-silvester) plötzlich 404 liefern.

Die Twig-Seite funktioniert korrekt (feature()-Aufrufe in menu.html.twig:59,66,74 und Default/station.html.twig:33 verstecken die Links) — das kaschiert den Bug nur.

Kontext/Risiko

Feature-Flags sind das einzige Gate vor unfertigen/kaputten Seiten. Aktuell sind per Flag deaktivierte Features öffentlich erreichbar; umgekehrt kann man Features nicht mehr per Flag abschalten (z. B. im Incident-Fall). Da drei der „geschützten" Seiten fatale Fehler werfen, ist das direkt produktionsrelevant.

Aufgaben

• Alle @Feature("…")-Docblocks in #[Feature('…')]-Attribute umwandeln (Flagception\Bundle\FlagceptionBundle\Attribute\Feature) — AnalysisController (4×), StationController (1×)
• Flag-Namen konsolidieren: coronaFireworksAction → analysis_fireworks_corona (oder Config-Flag umbenennen), totes/inkonsistentes Flag bereinigen
• Verifizieren: deaktiviertes Flag ⇒ 404 (Functional-Test je geflaggter Route, siehe Test-Issue)
• Prüfen, ob station_history/analysis_* nach Reparatur (Elastica-Issue) wieder aktiviert werden sollen

Abhängigkeiten

Eng verzahnt mit dem Issue „Sechs Routen liefern garantiert HTTP 500"; Erreichbarkeits-/Härtungskontext: #521, #526.

[maltehuebner]

Audit gegen aktuellen main

Der beschriebene Bug (Flagception 6 wertet nur PHP-Attribute aus, Docblock-@Feature-Annotationen sind wirkungslos) trifft grundsätzlich zu, aber die im Issue genannte Angriffsfläche ist auf aktuellem main fast vollständig verschwunden:

• AnalysisController existiert nicht mehr (im Zuge des Elasticsearch-/Analysis-Cleanups entfernt). Damit sind alle vier dort genannten @Feature-Annotationen und die Flags analysis_fireworks, analysis_komfortofen, analysis_fireworks_corona weg. Der beschriebene Flag-Namens-Mismatch (analysis_fireworks vs. analysis_fireworks_corona) ist gegenstandslos.
• config/packages/flagception.yaml enthält nur noch station_history: { default: false }.
• Die einzige verbliebene @Feature-Docblock-Annotation ist @Feature("station_history") an StationController::historyAction — genau die Route, die laut [Kritisch] Sechs Routen liefern garantiert HTTP 500: Referenzen auf entfernte/nie existierende Klassen (Elastica, DateTimeUtil, Sensio) #534 garantiert HTTP 500 wirft, weil HistoryDataFactory nie lauffähigen Code enthält.

Auflösung über #534

Statt die wirkungslose Docblock-Annotation in ein #[Feature]-Attribut zu konvertieren (was die kaputte historyAction hinter einem false-Flag nur kaschieren würde — aktivierbar wäre sie wegen des toten HistoryDataFactory weiterhin nicht), entfernt PR #534 das gesamte kaputte History-Feature: Route, Controller-Action, HistoryDataFactory(+Interface), Template, Menü-Link und den station_history-Flag.

Nach Merge von #534 gibt es keine @Feature-Docblocks, keine feature()-Twig-Aufrufe und keine konfigurierten Flags mehr — der hier beschriebene Bug hat dann keine betroffene Codestelle mehr.

Empfehlung

Dieses Issue kann nach Merge von #534 geschlossen werden (superseded). Sollten künftig neue Feature-Flags gebraucht werden, unbedingt native #[Flagception\Bundle\FlagceptionBundle\Attribute\Feature('…')]-Attribute verwenden, nicht @Feature-Docblocks.

(Kein separater PR, um Konflikte mit #534 auf derselben Codestelle zu vermeiden.)