Der Bug, der schon mal gefixt war

Drei kleine Geschichten aus den letzten Wochen, die alle auf dasselbe hinauslaufen: Der auffällige, laute Fehler ist selten der interessante Teil. Interessant wird es bei dem, was eine Typprüfung anstandslos durchwinkt, bei dem, was ein überlasteter Server bloß vorübergehend vorgaukelt — und bei dem Fix, der längst existierte, nur eben nirgends außer auf einer einzelnen SD-Karte.

XTEINC-X4: Von der Offline-Notizmaschine zur Bluetooth-Odyssee

Der CrossPoint-Firmware-Fork für meinen XTEINC-X4-E-Reader hat sich in den letzten Wochen vom reinen Lesegerät zu einer kleinen Offline-Schreibmaschine entwickelt: ein lokaler Markdown-Editor mit Autosave direkt auf der SD-Karte, ein Homescreen-Einstieg dafür, und beim eBook-Sync werden fertige Notizen automatisch in den Obsidian-/Nextcloud-Vault hochgeladen — erfolgreich Hochgeladenes wird lokal gelöscht, Fehlgeschlagenes bleibt als Outbox erhalten.

Damit brauchte das Gerät endlich eine zuverlässige Bluetooth-Tastatur — und genau die wollte lange nicht mitspielen. Der Weg dorthin war ein Lehrstück in Embedded-Debugging ohne eigenen Hardwarezugriff: Ein erster Fix-Versuch war Tage zuvor als “hat die Verbindung komplett zerschossen” verworfen worden, ohne dass klar war, warum. Ein genauer Diff-Vergleich zeigte: Der Patch änderte nur die Interpretation eingehender Bluetooth-Reports, nicht die Verbindungslogik — kein offensichtlicher Grund für einen Verbindungsabbruch. Auf dieser Basis entstand ein neuer, isolierter Branch direkt vom letzten bestätigt-stabilen Stand.

Von dort ging es an die eigentliche Shift-Taste, die einfach nicht ankommen wollte, plus doppelt eingegebene Buchstaben. Ein Vergleich mit einer verwandten, funktionierenden Firmware (MicroSlate) entlarvte einen nie an echten Rohdaten verifizierten Modifier-Zwischenspeicher im Bluetooth-Stack — dessen Entfernung Shift teilweise, aber nicht durchgehend reparierte. Die Diagnose danach brachte gleich zwei selbst verursachte Nebenwirkungen mit sich: Ein neuer, weicher (rein visueller) Zeilenumbruch machte das Rendern spürbar langsamer und öffnete ein Zeitfenster für eine Race Condition zwischen Render- und Haupt-Task — ein Absturz. Der erste, grobe Lock dagegen brachte prompt Buchstaben-Dopplungen zurück, weil er den Haupt-Task lang genug blockierte, um die eigene Dopplungserkennung zu verwirren. Erst ein dedizierter, kurzlebiger Mutex hat beides sauber gelöst, ohne das eine gegen das andere einzutauschen.

Weil eine USB-Serial-Live-Auswertung der rohen Bluetooth-Bytes auf dem Entwicklungsrechner schlicht nicht funktionierte, wanderte die gesamte Tiefendiagnose auf die SD-Karte: ein neues Sessionlog protokolliert seither sowohl dekodierte Tastendrücke als auch die rohen Bluetooth-Report-Bytes, komplett kabellos. Und dann, kurz nachdem all das stand, verband sich die Tastatur plötzlich gar nicht mehr — “verbindet kurz, trennt sofort”. Ein Rückroll auf ein älteres, bereits getestetes Binary half nicht, was die zuletzt gebaute Änderung als Ursache eindeutig ausschloss. Die eigentliche Ursache lag viel tiefer: Der Wiederverbindungs-Code probierte schon länger immer nur den allerersten gespeicherten Bluetooth-Bond. Hatten sich über die vielen Kopplungsversuche der letzten Wochen mehrere Bonds angesammelt und saß die aktive Tastatur nicht mehr im ersten Slot, hing die Verbindung faktisch für immer fest. Der interessanteste Teil: Genau dieser Bug war schon einmal gefunden und gefixt worden — der Fix existierte aber nur als lokales Testbinary und war nie tatsächlich committet worden, also beim nächsten Rebuild spurlos wieder verschwunden.

ElektraLog: Nicht jeder Monteur braucht die ganze Firmendatenbank

Bislang lud jedes Gerät beim Synchronisieren restlos alles herunter — bei wachsender Kundenzahl unnötig viel Datenvolumen für Monteure, die eigentlich nur an einem einzigen Standort arbeiten. Die Lösung: Die Kundenliste bleibt immer vollständig sichtbar, aber der datenintensive Teil (Komponentenbaum, Messwerte, Sichtprüfungen) wird nur noch für explizit ausgewählte Standorte oder einzelne Verteiler heruntergeladen. Zwei Architekturfragen wurden bewusst vor dem Bauen geklärt: Die Auswahl ist eine reine Geräteeinstellung, keine firmenweite Datenbank-Änderung — und ein Abwählen löscht nie automatisch lokale Daten, es stoppt nur künftige Downloads.

Ein subtiler Fehler zeigte sich erst beim echten Testlauf gegen eine laufende Datenbank: Eine Liste von UUIDs, als Text übergeben, gegen eine Datenbankspalte vom Typ UUID zu vergleichen, lässt sich von jeder Programmiersprachen-Prüfung anstandslos durchwinken — scheitert aber zur Laufzeit, weil die Datenbank diese beiden Typen nicht automatisch ineinander umwandelt. Nur der echte Testlauf gegen einen frisch aufgesetzten Server hat den Fehler vor der Auslieferung sichtbar gemacht.

MyPet und Ansible: Wenn der Build-Server in die Knie geht

MyPet bekam für alle fünf Zugänge (Tierbesitzer, Tierarzt, Dienstleister, Superadmin, jeweils Web und Android) ein eigenständiges visuelles Designsystem statt eines geteilten Einheitslooks, dazu nachgerüstete Medien-Verschlüsselung für Uploads und ein komplettes Produktions-Deployment — inklusive eines Servers, der unter parallelen Builds so weit ins Swapping geriet, dass selbst neue SSH-Verbindungen scheiterten. Der pragmatische Workaround: Images woanders bauen, komprimiert rüberschieben, Docker neu starten. Aus derselben Session ist außerdem der Grundstein für ein neues Ansible-Projekt zur Verwaltung der eigenen Server-Flotte entstanden.

Fazit

Alle drei Geschichten haben denselben blinden Fleck gemeinsam: Keiner der Fehler wäre bei einer rein statischen Prüfung aufgefallen. Die UUID-Verwechslung sah für den Compiler tadellos aus. Der überlastete Server meldete Dienste als “unhealthy”, obwohl sie nur noch am Hochfahren waren. Und der verlorene Bond-Rotation-Fix stand nirgends im Code, weil er ihn nie erreicht hatte. Zuverlässigkeit zeigt sich selten im ersten Testlauf — sie zeigt sich darin, ob man bereit ist, einen Fund auch dann noch einmal zu committen, wenn er beim ersten Mal schon einmal da war.