Troubleshooting-Leitfaden für das Gesamtprojekt
Troubleshooting-Leitfaden für das Gesamtprojekt
~9 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Jeder Block dieser Serie hatte sein eigenes kleines Troubleshooting-Kapitel oder zumindest einen warn()-Hinweis zum jeweils typischsten Fehler. Dieses Kapitel bündelt sie zu einem einzigen Nachschlagewerk, sortiert nach Symptom statt nach Ursache - so, wie ein Fehler im echten Betrieb zuerst auffällt.
Die allgemeine Diagnose-Reihenfolge
Bevor man ein einzelnes Symptom aus der Liste unten sucht, lohnt sich immer zuerst dieselbe generische Abfolge - für praktisch jedes der folgenden Probleme der schnellste erste Schritt:
bin/magento cache:flush
bin/log exception.log
bin/log mironsoft_loyalty.log
bin/magento deploy:mode:show
bin/magento setup:di:compileSymptom-Tabelle
- Punkte werden nach Bestellabschluss nicht gutgeschrieben. Wahrscheinlichste Ursache: Exception innerhalb von
AwardPointsOnOrderPlacedwurde von dessen eigenemtry/catch (\Throwable)abgefangen (Kapitel 30) und landet ausschließlich invar/log/mironsoft_loyalty.log(Kapitel 34), nicht inexception.log- der Checkout selbst läuft unauffällig weiter durch. Erster Schritt:bin/log mironsoft_loyalty.logstattexception.log. - Punkte werden doppelt gutgeschrieben, wenn ein Punkte-Paket gekauft wird.
loyalty_points_multiplier(Kapitel 19) wurde auf dem Punkte-Paket-Produkt nicht auf0gesetzt - sowohlAwardPointsOnOrderPlaced(Kapitel 30) als auchCreditPurchasedPointsPackageOnOrderPlaced(Kapitel 76) buchen dann unabhängig voneinander Punkte für dieselbe Bestellung, siehe die dokumentierte Praxis-Empfehlung aus Kapitel 76. - Admin-Grid zeigt keine oder falsche Prämien. Entweder ein falsch aufgebauter EAV-Collection-Filter (
addAttributeToFilter()statt der Kapitel-15-HelferaddActiveFilter()/addRewardTypeFilter()) oder ein neues Attribut, das nur demDefault-Set zugeordnet wurde, siehe die Warnung aus Kapitel 19/20. - PHPStan meldet einen Fehler direkt nach dem Anlegen eines neuen Configuration Type.
setup:di:compilevergessen oder nur einmal statt zweimal ausgeführt - derselbe Fallstrick wie beimtypes-Array-Merge aus Kapitel 88/99 (feedback_di_xml_compile_gotcha). - Eine GraphQL-Query liefert unerwartet
nullnach einer Schema-Änderung. Derconfig-Cache wurde nach der Änderung anschema.graphqlsnicht geleert -bin/cache-clean configreicht, keinsetup:di:compilenötig (Kapitel 82/83, konsistent mit der GraphQL-Serie dieses Katalogs). - Ein Kunde bekommt beim Einlösen wiederholt HTTP 429. Kein Bug -
RedemptionRateLimiter(Kapitel 86) hatMAX_ATTEMPTS = 5innerhalb vonWINDOW_SECONDS = 60erreicht. Prüfen, ob der Client tatsächlich fehlerhaft wiederholt aufruft, nicht das Limit selbst anheben, ohne den Grund zu verstehen. - Die neue Zahlungsart erscheint nicht im Checkout. Entweder
AvailabilityHandler::handle()(Kapitel 64) liefertfalse, weilquote.loyalty_points_to_redeemnoch0odernullist, oder die Knockout-Renderer-Registrierung incheckout_index_index.xml(Kapitel 65) fehlt nach einem Static-Content-Deploy ohne Admin-Bereich - siehe Kapitel 99, Schritt 6. - Die Gratisversand-Option erscheint nicht in der Versandartenliste.
FreeShippingByPoints::collectRates()(Kapitel 66/67) liefert konsequentfalsestatt eines leerenResult, sobaldpoints_costden aktuellen Punktestand übersteigt - das ist beabsichtigtes Verhalten, kein Fehler, siehe die Kapitel-67-Begründung. company_form.xmlzeigtloyalty_tier_overridenicht an.AddLoyaltyTierOverridePlugin(Kapitel 22) prüftMagento_Companys Verfügbarkeit nicht selbst - fehlt das Modul im System, schlägt schon dieextension_attributes.xml-Validierung fehl, siehe Kapitel 98.setup:upgradebricht mit einem Data-Patch-Fehler ab. Meist eine falsche oder zyklischegetDependencies()-Deklaration - der vollständige, korrekte Abhängigkeitsgraph aller zwölf Patches steht in Kapitel 99.- Der
ExpirePoints-Cronjob taucht als "missed" incron_scheduleauf. Entweder die Crongroupmironsoft_loyalty(Kapitel 32) ist nicht aktiv, oder die Reconciliation-Abfrage überschreitetschedule_lifetimemangels Index auf dem Ledger - siehe die Performance-Warnung aus Kapitel 100.
Das bekannte Restrisiko: Race Conditions
Achtung: Zwei parallele Einlösungen desselben Kunden (Storefront-Checkout und mobile App gleichzeitig, zum Beispiel) können denselben Punktestand doppelt verbrauchen - dokumentiert, aber bewusst nicht behoben in Kapitel 63, 81 und 86, mangels SELECT ... FOR UPDATE. Dieses Symptom zeigt sich nicht als Fehler, sondern als ein loyalty_points_balance, der nach zwei fast zeitgleichen Bestellungen kurzzeitig negativ oder unplausibel niedrig wird - kein Zufall, sondern die bereits an drei Stellen dieser Serie dokumentierte Lücke.
Wer diese Serie als Vorlage für ein echtes Modul nutzt, sollte nicht am selben Punkt aufhören, an dem dieses Tutorial aus didaktischen Gründen aufgehört hat - genau darum geht es in Kapitel 104, das weiterführende Serien dieses Katalogs zeigt.