Die Fehlermeldung log — viermal in einer Woche

Manche Wochen haben einen Plan. Diese hier hatte ein Muster: Immer wieder war die naheliegende Erklärung falsch, und die eigentliche Ursache saß eine oder zwei Schichten tiefer. Ein Matrix-Server, der angeblich keine Videoanrufe kann. Ein E-Reader, der an einer kleineren Datei hängen blieb. Eine Rechnung, deren Checkbox “alles ausgewählt” anzeigte, während im Hintergrund zwei Drittel der Positionen verschwanden. Dazwischen: ein komplett neues Blog-Design, ein Prototyping-Skill, der sich sofort im Ernstfall bewähren musste, und — als bewusster Kontrast zum Debugging — ein Pen-&-Paper-Rollenspiel für Vorschulkinder.

Wenn die Fehlermeldung in die Irre führt

Der Auftakt kam vom eigenen Matrix/Synapse-Server. Videoanrufe verweigerten mit “Der Server unterstützt das nicht” — eine Meldung, die sich wie ein fehlendes Feature liest. War es nicht. Eine saubere Bestandsaufnahme zeigte: 1:1-Anrufe liefen längst über einen korrekt konfigurierten TURN-Server. Das eigentliche Problem steckte in den Gruppenanrufen (Element Call) — der Server bewarb einen Verbindungspunkt in einem veralteten Format, hinter dem gar kein Dienst mehr lief. Eine halbfertige, vor längerer Zeit abgebrochene Konfiguration zwang den Client aktiv in den Fehler.

Der Fix kam ohne neue Subdomain aus: ein LiveKit-Server für Gruppenanrufe plus ein JWT-Dienst zur Authentifizierung, beide per Pfad-Routing unter der bestehenden Domain in den bestehenden Reverse Proxy gehängt — reloaded ohne Ausfall für die anderen 27 Domains, die auf demselben Proxy laufen. Dazu zwei Härtungen: TURN jetzt auch verschlüsselt über Port 5349 für Clients hinter strikten Firewalls, und großzügigere UDP-Puffer, die vorher Warnungen produzierten.

Am selben Tag, komplett unabhängig: die überarbeitete Fassung eines Romans ließ den E-Reader beim Indexieren hängen — obwohl die neue Datei kleiner war als die alte. “Kleiner” hieß hier nicht “harmloser”. Die Markdown-zu-EPUB-Pipeline hatte typografische Zeichen in benannte HTML-Entities verwandelt, die im strengen XHTML-Format schlicht nicht erlaubt sind. Tolerante Reader schluckten das, der strikte Indexer des E-Readers nicht — 16 von 21 Kapiteln waren dadurch nicht wohlgeformtes XML. Dazu ein zweiter, hausgemachter Fund: Steuer-Tags des eigenen Schreibwerkzeugs waren versehentlich mit ins Manuskript gerutscht und mitcommittet worden. Beides bereinigt, ein XML-Validierungsschritt fest in den Build eingebaut, und zur Sicherheit das Bilder-Budget spürbar gesenkt (nur noch referenzierte Bilder, kleineres Cover). Ergebnis: 21 von 21 Kapiteln wohlgeformt statt vorher vier.

Die dritte und aufwendigste Runde dieses Musters betraf saasERP, das selbstgebaute ERP-System: Eine Materialabschlagsrechnung ließ sich nicht als PDF erzeugen — und enthielt bei genauerem Hinsehen auch nur einen Bruchteil der eigentlichen Positionen. Die Wurzel war eine ID-Kollision: Wird dasselbe vordefinierte Produkt in mehreren Räumen eines Auftrags verwendet, vergab das Backend für jede Verwendung dieselbe technische ID. Die Auswahl-Logik im Bedienoberfläche verwaltet ausgewählte Positionen in einer Menge, die Duplikate automatisch zusammenfasst — die Checkboxen zeigten dabei täuschend korrekt alle Räume als ausgewählt an, aber beim Erstellen der Rechnung wurde pro doppelter ID nur der erste Treffer übernommen. Eine stille Datenkorruption, kein Absturz, keine Fehlermeldung.

Der Fix: Jede synthetische ID bekam einen Bezug zur konkreten Auftragsposition statt nur zur Produkt-Vorlage. Danach folgte ein echter End-to-End-Test über die tatsächliche API — nicht nur Code gelesen, sondern eine Testrechnung über elf Raum-Gruppen erzeugt, auf doppelte IDs geprüft und das erzeugte PDF Seite für Seite visuell kontrolliert. Direkt im Anschluss der zweite, viel banalere Fund: Für Rechnungen fehlte in der Oberfläche schlicht der PDF-Button, den es bei Angeboten und Bestellungen längst gab. Schnell nachgezogen — und prompt ein drittes Mal dasselbe Muster erlebt, diesmal in Miniatur: Der neue Button war nach dem Deployment im Browser unsichtbar, weil ein Service Worker beharrlich die alte, zwischengespeicherte Version der Web-App auslieferte. Ein harter Reload hat gereicht.

Selbstgehostete Infrastruktur: Aufräumen und Absichern

Neben dem Matrix-Umbau lief die übliche Selfhosting-Wartung — mit eigenen Überraschungen. Ein routinemäßiges Update des Cloud-Stacks (Nextcloud, Immich, Paperless, Collabora) endete in einer ungeplanten Datenbank-Migration: Die selbstgehostete Foto-Verwaltung Immich hat mit Version 3.0 die bisherige Vektor-Datenbank-Erweiterung komplett fallengelassen und verlangt jetzt eine andere. Der Server crash-loopte, bis Backup, korrektes Datenbank-Image und eine automatische Reindizierung durch waren. Sieben von acht Containern aktualisierten sich dabei völlig klaglos — nur der eine hing an einer Weichenstellung, die sich nicht aus dem Versionsschema erraten ließ, sondern gegen die Registry verifiziert werden musste.

Im selben Aufwasch eine bewusste Datenschutz-Entscheidung: Der Foto-Dienst bleibt absichtlich nur im Heimnetz erreichbar, kein offener Port ins Internet. Aus einem alten “TODO: Route korrigieren” in der Infrastruktur-Doku wurde ein klarer Vermerk “bewusst nicht öffentlich — nicht korrigieren”, damit kein künftiger Wartungslauf versehentlich die Tür aufmacht.

Zum Wochenschluss dann ein größerer Cut: Die Matrix-Instanz sammelte über Monate rund zwanzig automatisiert registrierte Spam-Accounts an — begünstigt durch offene Registrierung ohne Verifizierung. Erst ein vollständiges Backup, dann kompletter Reset von Datenbank, Signing-Key und Medien-Speicher. Die mühsam eingerichtete Anruf-Infrastruktur blieb dabei unangetastet, weil sie sauber von der Nutzerdatenbank getrennt ist. Parallel dazu wurde der eigene Obsidian-Vault (das Notizsystem hinter fast der gesamten Projektdokumentation) auf Echtzeit-Synchronisation über drei Geräte umgestellt — Laptop, ein Server als zusätzlicher Backup-Knoten und Smartphone —, während ein einzelner automatischer Commit-Punkt weiterhin für eine durchsuchbare Versionshistorie sorgt, ganz ohne manuelles Zutun.

OpenVault: Vom Nutzer-Wunsch zum funktionierenden Feature

Der Auslöser war reine Neugier: das Tasks-Plugin in Obsidian entdeckt — und sofort denselben Komfort in der eigenen Vault-App OpenVault haben wollen. Daraus wurde ein kleines Architektur-Projekt: Weil kompiliertes Flutter kein Laufzeit-Nachladen von Fremdcode erlaubt, entstand ein Add-On-System aus fest kompilierten, ein-/ausschaltbaren Feature-Modulen mit gemeinsamer Schnittstelle — gebaut, damit ein späteres Plugin-API später andocken kann, aber ohne die Komplexität heute schon vorwegzunehmen.

Kern des ersten Add-Ons: ein Aufgaben-Parser, der exakt die Syntax des Obsidian-Tasks-Plugins spricht, damit dieselbe Markdown-Datei in beiden Werkzeugen funktioniert. Reine, von Datei-Zugriff entkoppelte Logik zuerst — dadurch standen die ersten zwölf Tests in Minuten. Danach kamen Schritt für Schritt Query-Sprache, eine Abhak-Logik, die alle anderen Formatierungen einer Zeile unangetastet lässt, und das sichtbare Rendering von Aufgaben-Blöcken in der Web-App dazu, jeder Schritt einzeln getestet und sofort live deployed.

Der eigentliche Reifetest kam erst im echten Betrieb: Live-Feedback zeigte, dass der Aufgaben-Index in einer wichtigen Ansicht schlicht nicht ankam — ein fehlender Ein-Schalter für das Feature war die eine Ursache, eine Ansicht, die den Index nicht durchreichte, die andere. Kurz danach der zweite Fund: Filter zeigten scheinbar alle Aufgaben, egal was man einstellte. Der Parser ignorierte unbekannte Schreibweisen still, statt sie zu verstehen — vorwärtskompatibel, aber eben auch fehlertolerant bis zur Unsichtbarkeit. Beide Lücken gestopft, insgesamt 31 grüne Tests am Ende der Woche. Kompatibilität entscheidet sich an genau solchen Details: tag includes versus tags include, # optional oder nicht — Kleinigkeiten, an denen es hängt, ob dieselbe Notiz in beiden Werkzeugen wirklich gleich funktioniert.

Dieselbe Aufräumlust griff auch auf den eigenen Notiz-Alltag über: Die tägliche Notiz-Vorlage war mit sieben Abschnitten spürbar überladen — auf drei schlanke Abschnitte eingedampft, weil eine Vorlage, die man abends nicht ausfüllt, schlechter ist als gar keine.

Ein neues Blog-Design und ein Prototyping-Skill im Ernstfall

Dieser Blog trug bislang ein unverändertes Standard-Theme. Nach einem Design-Konzept komplett neu gestaltet: dunkles Farbschema mit einem ruhigen Amber-Akzent statt Standardblau, selbst gehostete Schriften statt Google-Fonts-CDN, die Beitragsliste jetzt als kompakte Log-Zeilen mit Datum, Lesezeit und Tags. Umgesetzt als reine Erweiterung über dem bestehenden Theme, ohne dessen Quellcode zu verändern — künftige Theme-Updates bleiben dadurch weiterhin möglich. Beim Testen fielen nebenbei zwei schlafende Fehler im Build auf, die beim nächsten großen Versions-Update hart fehlgeschlagen wären, und wurden gleich mit behoben.

Kurz danach entstand ein neuer Ansatz fürs schnelle Prototyping: Go (nur Standardbibliothek), HTMX für Interaktivität ganz ohne eigenes JavaScript, SQLite ohne Compiler-Abhängigkeiten — bewusst minimal und wegwerfbar gehalten, um neue Projektideen durchklicken zu können, bevor Zeit in die eigentliche Umsetzung fließt. Der Ansatz musste sich sofort zweimal im Ernstfall beweisen: einmal am Nachbau eines alten, mehrjährigen Studienprojekts (ein Kanban-Board, ursprünglich in reinem JavaScript) — komplett funktional in wenigen Stunden, inklusive automatisiert durchgeklickter End-to-End-Interaktionen. Und ein zweites Mal an einem Redesign-Entwurf für eine bestehende, produktiv laufende Life-Management-App: Dashboard, Aufgaben, Gewohnheiten-Tracking mit echter Datenbank-Logik (inklusive einer aus echten Nutzungsdaten berechneten Activity-Heatmap) und ein Haushaltsbuch, alles nach einem eigenständigen Material-Design-System gestaltet, das sich bewusst vom Blog-Look unterscheidet.

Kleinere Bausteine

Das Preismodell von ElektraLog wurde radikal vereinfacht: von vier Preisstufen, von denen drei nur “auf Anfrage” waren, auf drei klare Varianten mit echten Zahlen — kostenlose Solo-Nutzung, ein fester Cloud-Pauschalpreis pro Firma statt Nutzer-Staffelung, und kostenloses Self-Hosting dank MIT-Lizenz. Der Kniff dahinter: Der bezahlte Cloud-Preis verkauft Betrieb, nicht Software — das kostenlose Self-Hosting kannibalisiert das Angebot nicht, sondern schafft Vertrauen.

Und als bewusster Kontrast zum ganzen Debugging entstand ein komplettes Pen-&-Paper-Rollenspiel-Starterset für Vorschulkinder — Mini-Regelwerk, fertige Helden, ein Abenteuer, eine Anleitung für Erwachsene ohne jede Rollenspiel-Erfahrung. Die eigentliche Arbeit war Reduktion: ein Würfel, eine Schwelle, drei Herzen, niemand stirbt, Konflikte löst man mit Freundlichkeit statt Kampf. Dieselben Prinzipien, die sich sonst in Produkt-Design bewähren — radikal vereinfachen, den Normalfall zum Kinderspiel machen, Fehler harmlos halten — funktionieren erstaunlich direkt auch beim Regel-Design für Fünfjährige.

Fazit

Vier komplett unterschiedliche Systeme, dieselbe Lektion: Eine Fehlermeldung beschreibt oft ein Symptom, nicht die Ursache — und wer sofort am naheliegenden Verdächtigen schraubt, verliert Zeit an der falschen Stelle. Erst verstehen, dann anfassen. Das hat sich diese Woche viermal ausgezahlt, von einem Matrix-Server bis zu einer einzelnen Rechnung.