meldestelle/docs/99_Journal/2026-04-16_ZNS-Persistence-Fix.md
2026-04-16 23:45:23 +02:00

2.0 KiB

Journal-Eintrag: 2026-04-16 - Behebung Persistenz-Problem ZNS-Import

Problembeschreibung

Der ZNS-Import meldete "Erfolgreich", jedoch wurden keine Daten in der Postgres-Datenbank (pg-meldestelle-db) gespeichert.

Ursachenanalyse

  1. Profil-Einschränkung: Die ZnsImportDatabaseConfiguration im zns-import-service war mit @Profile("dev") annotiert. Da die Docker-Umgebung standardmäßig das Profil docker verwendet, wurde die Datenbankverbindung für Exposed (das vom ZnsImportService genutzt wird) nicht initialisiert.
  2. Fehlendes Logging: Der ZnsImportOrchestrator lief in einem asynchronen Coroutine-Scope ohne ausreichendes Logging bei Fehlern in der Persistenzschicht, was die Diagnose erschwerte.

Durchgeführte Änderungen

1. Konfiguration (Backend)

  • ZnsImportDatabaseConfiguration.kt: Die Einschränkung @Profile("dev") wurde entfernt. Die Datenbank-Initialisierung (Exposed Database.connect und Schema-Migration) erfolgt nun in allen Profilen ( einschließlich docker).
  • ZnsImportOrchestrator.kt: Debug-Logs ([DEBUG_LOG]) hinzugefügt, um den Status des Imports (Größe der ZIP, gefundene Dateien, Ergebnis-Zusammenfassung) in den Docker-Logs sichtbar zu machen.
  • ZnsImportService.kt: Logging der extrahierten Dateien und Zeilenanzahlen aktiviert.

2. Persistenz

  • Sicherstellung, dass Database.connect global für den Service aufgerufen wird, damit die Repositories (z.B. VereinExposedRepository) auf die korrekte Transaktions-Umgebung zugreifen können.

Verifikation

  • Prüfung der Konfigurationsdatei auf korrekte Entfernung der Annotation.
  • Validierung der Log-Ausgaben im Orchestrator.
  • Ein Rebuild des zns-import-service Docker-Images ist erforderlich, um die Änderungen zu aktivieren.

👷 [Backend Developer]: Persistenz-Layer für ZNS-Import gehärtet. 🏗️ [Lead Architect]: Datenbank-Initialisierung auf Profile-Agnostik umgestellt. 🧹 [Curator]: Dokumentiert in Journal am 16.04.2026.