meldestelle/docs/99_Journal/2026-04-16_ZNS-Serialization-Fix.md

📓 Journal-Eintrag: 2026-04-16 - ZNS-Import Serialization Fix

🏗️ Status Quo

Nach dem Deployment der ZNS-First Strategie trat beim Testen der Desktop-App ein Serialisierungsfehler auf: Serializer for class 'ImportStartResponse' is not found.

🚀 Analyse & Behebung

1. Das Problem

Die Kommunikation zwischen der Desktop-App (KMP/Compose) und dem zns-import-service (Spring Boot) nutzt kotlinx.serialization auf der Client-Seite.

• Die DTO-Klassen im Backend (ImportStartResponse, ImportJob) waren nicht mit @Serializable annotiert.
• Das Gradle-Plugin kotlin.plugin.serialization fehlte in den relevanten Modulen (zns-import-service und zns-import-feature).
• Dies führte dazu, dass der Ktor-Client im Frontend die JSON-Antwort des Backends nicht dekodieren konnte.

2. Die Lösung

• Backend: @Serializable zu ImportStartResponse, ImportJob und ImportJobStatus hinzugefügt.
• Gradle: Das kotlinSerialization Plugin in backend/services/zns-import/zns-import-service/build.gradle.kts und frontend/features/zns-import-feature/build.gradle.kts aktiviert.
• Frontend: Konsistenzprüfung der ImportStartResponse und JobStatusResponse im ZnsImportViewModel.

🛠️ Technische Details

• Module:
  • backend:services:zns-import:zns-import-service
  • frontend:features:zns-import-feature
• Änderungen:
  • ImportJobRegistry.kt: ImportJob & ImportJobStatus sind jetzt @Serializable.
  • ZnsImportController.kt: ImportStartResponse ist jetzt @Serializable.
  • build.gradle.kts: Plugins ergänzt.

🏁 Fazit

Der ZNS-Import-Workflow (Upload -> JobId -> Polling) ist nun technisch stabil und die Typen sind über die Systemgrenzen hinweg serialisierbar.

---

🧹 [Curator]: Dokumentation des Serialization-Fixes abgeschlossen. 👷 [Backend Developer]: DTOs für API-Kommunikation stabilisiert. 🏗️ [Lead Architect]: Konsistente Nutzung von Kotlinx-Serialization in KMP-Context sichergestellt.