2.0 KiB
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
- Profil-Einschränkung: Die
ZnsImportDatabaseConfigurationimzns-import-servicewar mit@Profile("dev")annotiert. Da die Docker-Umgebung standardmäßig das Profildockerverwendet, wurde die Datenbankverbindung für Exposed (das vomZnsImportServicegenutzt wird) nicht initialisiert. - Fehlendes Logging: Der
ZnsImportOrchestratorlief 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 (ExposedDatabase.connectund Schema-Migration) erfolgt nun in allen Profilen ( einschließlichdocker).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.connectglobal 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-serviceDocker-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.