# 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.