mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Add journal log: Fix Flyway migration issues in ping-service with service-specific schema history configuration.
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Waiting to run
Details
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Stefan Mogeritsch
2026-04-03 21:52:30 +02:00
parent 35f8b46e6c
commit 6c64444a98
1 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/99_Journal/2026-04-03_Ping_Service_Flyway_Fix.md
+24
View File
@@ -0,0 +1,24 @@
# Session Log: Behebung Flyway Migrations-Fehler im Ping-Service
**Datum:** 2026-04-03
**Agent:** Backend Developer / Curator
## Problembeschreibung
Der `ping-service` ließ sich via Docker nicht starten und warf eine `FlywayMigrateException` mit der Ursache `ERROR: relation "ping" does not exist`.
Die Log-Analyse zeigte, dass die Datenbankmigration `V2__seed_data.sql` fehlgeschlagen ist, weil die vorausgehende Migration `V1__init_ping.sql` (in der die Tabelle `ping` erstellt wird) offensichtlich nicht ausgeführt wurde.
## Ursachenanalyse
Die `application.yaml` des `ping-service` enthielt die Konfiguration `baseline-on-migrate: true`. Wenn mehrere Services (z. B. `masterdata-service`, `ping-service` etc.) dieselbe PostgreSQL-Datenbank (`pg-meldestelle-db`) und standardmäßig das Schema `public` nutzen, teilen sie sich ohne weitere Konfiguration die gleiche Flyway-Historientabelle (`flyway_schema_history`).
Wenn ein anderer Service bereits Migrationen ausgeführt oder die Datenbank initialisiert hatte, setzte Flyway für den `ping-service` eine Baseline mit Version `1`. Infolgedessen ignorierte Flyway die Datei `V1__init_ping.sql` und versuchte direkt, `V2__seed_data.sql` auszuführen. Dies führte zum Scheitern der Migration, da die notwendige Struktur aus `V1` fehlte.
## Lösung
1. **Isolierung der Flyway-Historientabelle:** In der `application.yaml` des `ping-service` wurde die Property `spring.flyway.table: flyway_schema_history_ping` hinzugefügt. Dadurch verwaltet der `ping-service` seinen eigenen Migrationsstatus unabhängig von anderen Services in der gleichen Datenbank.
2. **Anpassung der Baseline-Version:** Es wurde explizit `spring.flyway.baseline-version: "0"` konfiguriert, um sicherzustellen, dass V1-Skripte stets als Teil der Historie betrachtet werden, selbst falls Flyway in einer nicht leeren Datenbank ansetzt.
## Geänderte Dateien
* `/mocode/Meldestelle/backend/services/ping/ping-service/src/main/resources/application.yaml`
* `/mocode/Meldestelle/docs/05_Backend/Services/PingService_Reference.md` (Dokumentation aktualisiert)
## Nächste Schritte
* Die Infrastruktur sollte nun stabil hochfahren. (Ggf. Ping Service im Docker Stack neustarten).
* Diese Best Practice (spezifische `flyway.table` pro Service) sollte zukünftig auch bei anderen Microservices angewandt werden, die sich dasselbe DB-Schema teilen, um Konflikte zu vermeiden.