From 6c64444a980a7c347a7fbdf9ee06249f6281f63d Mon Sep 17 00:00:00 2001 From: StefanMoCoAt Date: Fri, 3 Apr 2026 21:52:30 +0200 Subject: [PATCH] Add journal log: Fix Flyway migration issues in ping-service with service-specific schema history configuration. --- .../2026-04-03_Ping_Service_Flyway_Fix.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 docs/99_Journal/2026-04-03_Ping_Service_Flyway_Fix.md diff --git a/docs/99_Journal/2026-04-03_Ping_Service_Flyway_Fix.md b/docs/99_Journal/2026-04-03_Ping_Service_Flyway_Fix.md new file mode 100644 index 00000000..40d99f9d --- /dev/null +++ b/docs/99_Journal/2026-04-03_Ping_Service_Flyway_Fix.md @@ -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.