meldestelle/docs/99_Journal/2026-04-03_Ping_Service_Flyway_Fix.md
StefanMoCoAt 6c64444a98
Some checks failed
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Waiting to run
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
Add journal log: Fix Flyway migration issues in ping-service with service-specific schema history configuration.
2026-04-03 21:52:30 +02:00

2.4 KiB

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.