Journal: Behebung von 500er Fehlern im Ping-Service & Security-Fixes

Datum: 19. April 2026 Status: Abgeschlossen Agent: 🏗️ [Lead Architect] | 🧐 [QA Specialist] | 🧹 [Curator]

🎯 Zielsetzung

Nach der gestrigen Umstrukturierung traten beim ping-service HTTP 500 Fehler bei autorisierten API-Aufrufen auf. Ziel war die Identifikation der Ursachen (Security, Parameter-Mapping, Resilience) und deren Behebung sowie die Aktualisierung der Testsuite.

🛠️ Durchgeführte Änderungen

1. Security-Mapping & Rollen-Korrektur

Im PingController wurden die @PreAuthorize-Annotationen korrigiert. Da der KeycloakRoleConverter das Präfix ROLE_ hartkodiert hinzufügt und die Rollen in Großbuchstaben umwandelt, wurden die Prüfungen von MELD_USER auf ROLE_MELD_USER (bzw. ROLE_MELD_ADMIN) angepasst.
Der Import der AccessDeniedException im PingExceptionHandler wurde auf die korrekte Spring Security Klasse fixiert, um 403-Fehler sauber zu fangen und nicht in 500er zu verwandeln.

2. API-Konsistenz & Parameter-Mapping

Der Query-Parameter für /api/ping/sync wurde explizit auf lastSyncTimestamp gemappt, um mit dem Postman-Aufruf und den Anforderungen des Frontends konsistent zu sein.

3. Resilience4j & Coroutines

Die Bibliothek resilience4j-kotlin wurde in die libs.versions.toml aufgenommen und im ping-service eingebunden. Dies stellt sicher, dass der @CircuitBreaker korrekt mit Kotlin suspend Funktionen zusammenarbeitet und Exceptions nicht unkontrolliert durchschlagen.

4. Test-Aktualisierung

PingControllerTest.kt wurde angepasst, um den neuen Parameter-Namen lastSyncTimestamp zu verwenden.
Alle 5 Tests im PingControllerTest verlaufen nun erfolgreich.

✅ Verifizierung

./gradlew :backend:services:ping:ping-service:test: ERFOLGREICH (5/5 Tests passed)
Manueller Check der Parameter-Namen gegen Postman-Anforderungen: ERFOLGREICH
Verifizierung des Rollen-Mappings im KeycloakRoleConverter gegen Controller-Annotationen: KONSISTENT

🧹 Fazit

Die "letzte Meile" der Service-Kommunikation ist nun stabil. Durch das verbesserte Exception-Handling und die korrekte Resilience-Integration liefert der Service nun aussagekräftige HTTP-Statuscodes statt generischer 500er Fehler.

Nachtrag 20:30

Networking-Fix: GlobalSecurityConfig angepasst, um jwk-set-uri primär aus Spring-Properties oder Environment-Variables zu lesen. Default auf localhost:8180 für IDE-Betrieb korrigiert, um UnknownHostException: keycloak zu vermeiden.
Exception-Handling: PingExceptionHandler um generischen Exception-Handler erweitert, um auch Security-Initialisierungsfehler (wie JWT-Decoder-Probleme) sauber abzufangen und zu loggen.

Nachtrag 21:25

Re-Fix Circuit Breaker Fallback: Nachdem ein fehlerhafter Zwischenversuch (möglicherweise durch einen anderen Agenten) die suspend-Markierung wieder eingeführt hatte, wurde diese nun final entfernt. Die Signatur fallbackPing(simulate: Boolean, ex: Throwable) ohne suspend ist die einzig stabile Variante für Resilience4j in Kombination mit Spring Boot 3 AOP-Proxies und Kotlin Coroutines. Tests bestätigen die strukturelle Korrektheit.

Nachtrag 21:45

Stochastic Simulation: Die Zufallskomponente (Random.nextDouble() < 0.6) wurde in der enhancedPing-Methode wieder eingeführt.
Logik: Wenn simulate=true übergeben wird, tritt der Fehler nun nur noch in ca. 60% der Fälle auf, was ein realistisches "intermittierendes" Fehlerszenario für den Circuit Breaker Test darstellt. In den restlichen 40% wird die Anfrage trotz Simulationsmodus erfolgreich verarbeitet.
Logging: Zusätzliches Log-Statement für den "Lucky Pass" Fall hinzugefügt, um die Simulationstransparenz in der Konsole zu wahren.

3.8 KiB Raw Blame History