wien-oepnv

Systemweiter Gesundheitscheck Wien ÖPNV Feed

Prüfansatz

• Vollständige Test-Suite (pytest) ausgeführt und Ergebnis protokolliert.
• Manuelle Code-Durchsicht der Kernmodule (src/build_feed.py, src/providers/*, src/utils/*) sowie der relevanten Tests, um Datenfluss, Fehlerbehandlung und Secret-Nutzung zu bewerten.
• Fokus auf die Fragen: Zweckmäßigkeit jeder Code-Passage, Zuverlässigkeit & Effizienz, sicherer Secret-Einsatz, API-Integration samt Stationsabgleich, Feed-Befüllung.

Codezweck & Struktur

• Pfad- und Log-Konfiguration erzwingen, dass Ausgaben ausschließlich innerhalb der whitelisten Wurzeln docs/, data/ und log/ liegen; ungültige ENV-Werte werden abgefangen bzw. auf sichere Defaults zurückgesetzt.【F:src/build_feed.py†L26-L157】
• Die Feed-Pipeline trennt Cache- und Netzwerk-Quellen, normalisiert Datumsfelder und führt Ergebnisse zusammen. Fehler einzelner Provider blockieren den Lauf nicht und werden mit Kontext geloggt.【F:src/build_feed.py†L461-L530】
• Veraltete oder doppelte Items werden durch _drop_old_items und _dedupe_items zuverlässig entfernt. Dabei werden Enddaten, First-Seen-State und Beschreibungslängen verglichen, um inhaltlich sinnvollere Einträge zu priorisieren.【F:src/build_feed.py†L533-L638】

Zuverlässigkeit & Effizienz

• Netzwerkabrufe laufen parallel in einem ThreadPoolExecutor, Timeout-Überschreitungen führen zu sauberem Abbruch und Logging ohne das Gesamtergebnis zu verlieren. Über die ENV-Variable PROVIDER_MAX_WORKERS lässt sich die gleichzeitige Thread-Anzahl begrenzen, um Ressourcen zu schonen.【F:src/build_feed.py†L469-L551】
• Provider-spezifische Clients nutzen gemeinsame Retry-Sessions (session_with_retries) und JSON-Validierungen; ungültige Antworten lösen Warnungen statt Abstürzen aus.【F:src/providers/wl_fetch.py†L303-L419】【F:src/providers/vor.py†L485-L520】
• Stations-Hilfsfunktionen normalisieren Aliasnamen, prüfen auf Wiener Stadtgebiet und verknüpfen Wiener-Linien- sowie VOR-IDs, was den Abgleich stabilisiert.【F:src/utils/stations.py†L13-L200】

Secrets & Konfiguration

• Die VOR-Zugangsdaten werden ausschließlich aus ENV-Variablen bezogen; Standardwerte folgen der offiziellen VAO-Dokumentation. Vor jedem Logging werden accessId-Fragmente maskiert, Tests stellen das sicher.【F:src/providers/vor.py†L270-L415】【F:tests/test_vor_accessid_not_logged.py†L1-L53】
• Konfigurationswerte (Timeouts, Limits, Pfade) werden über geprüfte ENV-Helfer geladen, die ungültige Eingaben protokollieren und auf sichere Defaults zurückfallen.【F:src/utils/env.py†L16-L64】

APIs, Stationen & Feed-Befüllung

• Wiener-Linien-Feed filtert inaktive Meldungen, bereinigt HTML und leitet stabile Identitäten für first_seen ab, bevor Events in den Feed übergeben werden.【F:src/providers/wl_fetch.py†L344-L419】
• Der VOR-Provider löst Stationsnamen zu IDs auf, kapselt Request-Limits über atomare Zähler und versieht Fehler mit sanitisierten Tokens, wodurch APIs trotz Rate-Limits konsistent bleiben.【F:src/providers/vor.py†L398-L520】【F:src/providers/vor.py†L828-L858】
• Feed-Ausgabe erfolgt in docs/feed.xml; Text wird sanitisiert (z. B. Kontrollzeichen, CDATA) und optional gekürzt, damit Konsumenten valides XML erhalten.【F:src/build_feed.py†L182-L288】【F:src/build_feed.py†L640-L734】

Tests & Monitoring

• Die automatisierte Testsuite deckt Parser, State-Verwaltung, Secret-Maskierung und Provider-Kantenfälle ab; aktueller Lauf: 257 erfolgreiche Tests in 30.90 s.【aed3bc†L1-L14】
• Logging richtet einen rotierenden Fehler-Handler ein (log/errors.log), sodass auffällige Situationen nachvollziehbar bleiben.【F:src/build_feed.py†L69-L103】

Handlungsempfehlungen

1. Timeout-Tuning pro Provider – PROVIDER_TIMEOUT gilt global; für sehr langsame Quellen könnten separate ENV-Overrides erwogen werden, obwohl der aktuelle Default robust ist.【F:src/build_feed.py†L140-L162】【F:src/build_feed.py†L516-L533】
2. Cache-Monitoring – Ungültige oder fehlende Cache-Dateien führen zu Warnungen; ergänzendes Alerting würde schneller auf defekte Importe aufmerksam machen.【F:src/utils/cache.py†L12-L60】
3. Stationsdateien pflegen – Die Fallback-Liste data/vor_station_ids_wien.txt sollte gepflegt werden, damit neue Linien ohne ENV-Anpassung einfließen.【F:src/providers/vor.py†L287-L315】
4. WL-Timeout pro Feed-Typ differenzieren – Beide Wiener-Linien-Endpunkte teilen sich aktuell einen gemeinsamen Timeout. Ein separates Limit pro API-Aufruf könnte lange blockierende trafficInfoList-Anfragen abfedern, während newsList weiterhin schnell antwortet.【F:src/providers/wl_fetch.py†L303-L341】

Nachverfolgung

• Cache-Monitoring – Die Registrierung von Hooks für Cache-Warnungen ist jetzt thread-sicher. Gleichzeitige An- und Abmeldungen werden durch ein Re-Entrant-Lock koordiniert, wodurch Race-Conditions in stark parallelisierten Szenarien vermieden werden.【F:src/utils/cache.py†L12-L58】

• Bytecode-Cleanup – Versehentlich versionierte Python-Bytecode-Caches (src/providers/__pycache__) wurden entfernt und .gitignore präzisiert, sodass künftige __pycache__-Verzeichnisse repositoryweit ausgeschlossen bleiben.【F:.gitignore†L1-L2】

• Performance-Monitoring – Ergänzend zum bisherigen Logging existiert nun ein dokumentiertes Konzept für Laufzeitmetriken, Alarme und Profiling-Workflows (docs/performance_monitoring_plan.md). Damit ist die im Audit empfohlene Beobachtung der Feed-Performance umgesetzt.

Insgesamt bestätigt der aktuelle Stand eine zweckmäßige, robuste und sichere Umsetzung der Feed-Generierung. Kritische Fehler oder Sicherheitsmängel wurden nicht gefunden; die genannten Empfehlungen betreffen proaktives Betriebs-Finetuning.

This site is open source. Improve this page.