StefanMoCoAt c51773a4c7 chore(docs+infra): update roadmap, improve home server plan, and archive outdated reports

- Adjusted infrastructure roadmap to use VM instead of nested LXC for Docker hosting, enhancing isolation and compatibility.
- Clarified multi-architecture CI/CD setup with native ARM64 builds and QEMU-based x86_64 builds.
- Updated documentation to include backup and offline-first strategies.
- Archived outdated session logs and reports for better file organization.

2026-02-06 20:49:47 +01:00

3.3 KiB

Raw Blame History

type

status

owner

date

participants

Journal

COMPLETED

Curator

2026-01-26

Lead Architect

DevOps Engineer

QA Specialist

Curator

Session Log: 26. Jänner 2026

Zielsetzung

Stabilisierung der Web-Applikation (Wasm/JS) und Behebung von Datenbank-Initialisierungsfehlern (WebWorkerException) im Browser.

Durchgeführte Arbeiten

1. Web-App Datenbank (SQLDelight & Wasm)

Problem: Die Web-App startete nicht mit einer WebWorkerException. Ursache war, dass der Web Worker (sqlite.worker.js) und die zugehörige WASM-Datei (sqlite3.wasm) vom Browser nicht gefunden oder falsch geladen wurden.
Lösungsversuche:
- Aktivierung des Wasm-Targets (revertiert, da zu viele Folgefehler).
- Anpassung der Gradle-Tasks (copySqliteAssetsToWebpackSource, copySqliteAssetsToDist), um Assets korrekt zu kopieren.
- Anpassung des Workers (sqlite.worker.js) für manuelles Laden der WASM-Datei via fetch.
- Webpack-Hacks: Umfangreiche Anpassungen in webpack.config.d/ignore-sqlite-wasm.js, um Webpack daran zu hindern, sqlite3.wasm als Modul zu parsen (was fehlschlug) und stattdessen auf ein dummy.js umzuleiten.
Aktueller Stand:
- Der Build schlägt noch fehl mit export 'default' ... was not found.
- Die Strategie ist: Webpack sieht dummy.js (als Ersatz für sqlite3.mjs und sqlite3.wasm), während der Worker zur Laufzeit die echte sqlite3.wasm Datei manuell lädt.
- dummy.js muss so angepasst werden, dass es einen korrekten Default-Export bereitstellt.

2. Unit Tests (Ping Feature)

Problem: PingViewModelTest schlug fehl, da Fehlerzustände nicht korrekt im UI-State gesetzt wurden.
Lösung: PingViewModel angepasst, um errorMessage im State bei Exceptions korrekt zu setzen. Tests sind wieder grün.

3. Gradle Build Optimierung

Problem: Zirkuläre Abhängigkeiten zwischen Copy-Tasks und Webpack-Tasks.
Lösung: Task-Reihenfolge in build.gradle.kts korrigiert (mustRunAfter statt dependsOn wo nötig).

Offene Punkte & Nächste Schritte

Web-App Build Fix:
- dummy.js muss einen Default-Export (export default function...) bereitstellen, um den Import in sqlite.worker.js zu befriedigen.
- Danach sollte der Webpack-Build durchlaufen.
- Laufzeit-Test im Browser: Prüfen, ob der manuelle fetch im Worker funktioniert und die DB initialisiert wird.
Wasm-Strategie:
- Langfristig sollte auf natives Wasm-Target umgestellt werden, sobald die Toolchain (Kotlin/Wasm + SQLDelight) stabiler ist. Aktuell ist der JS-Interop-Weg mit Webpack-Hacks notwendig.
Integration Test:
- Sobald die Web-App läuft: Vollständiger Durchstich (Login -> Ping -> DB Sync) im Browser testen.

Technische Erkenntnisse

Webpack & Wasm: Webpack 5 tut sich schwer mit dynamischen require-Aufrufen in Libraries wie sqlite-wasm, wenn diese nicht explizit als externals oder via NormalModuleReplacementPlugin behandelt werden.
SQLDelight im Browser: Die Kombination aus OPFS (Origin Private File System), Web Workern und Wasm erfordert präzise Kontrolle über das Laden der Assets, die Webpack oft "wegabstrahieren" will.

Status: 🟡 Build Failing (Web) / 🟢 Tests Passing (JVM)

3.3 KiB Raw Blame History