Hallo,
beim Ausführen des Steps PlentyUpdateVariations erhalten wir oft den Fehler 40001. Leider können wir damit nicht viel Anfangen.
Gibt es Informationen dazu, wie diesem entgegengetreten werden kann und was die Ursache dafür ist?
Error setting variations: Unknown Error (SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction (SQL: update `plenty_item_variation_base` set
Vielen Dank,
Christian Sobek
Hallo Christian,
die Fehlermeldung kommt aus der Response von Plenty. Bei Plenty scheint es beim Updaten der Variante zu einem Datenbankproblem zu kommen. Geht der Log Eintrag im Eventlog noch weiter? Wird da eventuell eine Varianten ID geloggt ? Falls ja, tritt der Fehler beim mehrmaligen Ausführen des Flows immer bei der gleichen Variante auf ?
VG Torsten
17: Error setting variations: Unknown Error (SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction (SQL: update `plenty_item_variation_base` set `plenty_item_variation_base_availability_timestamp` = 2019-03-21T14:55:26+01:00 where `plenty_item_variation_base_primary_variation_id` = 693586 and `plenty_item_variation_base_availability` is null)) occurred.
Das ist die gesamte Meldung. Beim erneuten Ausführen kommen gleiche Meldungen nur zu anderen Varianten. Habe für diese Variante noch mal den Flow laufen lassen und erfolgreich beendet. Also kein Fehler für diese Variante.
Viele Grüße.
Danke, dann liegt es vermutlich nicht an dem REST API Request von uns.
Der Fehler kommt wie schon geschrieben von Plenty. Ein Deadlock tritt im Normalfall auf, wenn jemand anderes / ein anderer Prozess auch gerade diese Variante aktualisiert.
Danke für die Information. Laut Plenty kann das vorkommen. Aber natürlich ist eine Stapelverarbeitung für uns nicht viel Wert, wenn wir bei jeder Ausführung Fehler erhalten und kaum sicher sein können, dass alles passt. Zudem ist es auch nicht auszuwerten, was schief gegangen ist, sodass nachgebessert werden kann.
Könnte bitte zugearbeitet werden, welcher Rest Request hier abgesetzt wird, damit Plenty die Ursache eingrenzen kann? Schön wäre es natürlich, wenn dieses Verhalten direkt zwischen Plenty und Synesty geklärt werden kann, da es sonst ein Stille-Post Spiel ist. Der Step "PlentyUpdateVariations" funktioniert quasi nicht für mehr als 100 Varianten ohne Fehler.
Anbei der Link zum Thread bei Plenty:
Dank vielmals.
Bitte aktiviere mal bei diesem Flow den Debug Modus, lass den Flow laufen und sag Bescheid (mit Angabe der RunID), wenn es wieder fehlgeschlagen ist. Bitte auch einen Support-Nutzer anlegen, falls aktuell noch nicht geschehen, damit wir uns den Debug-Log laden können.
Mit den Informationen aus dem Debug-Modus können wir dann den Request ermitteln, der über die Leitung geht.
Evtl. bringt das plenty auf eine heiße Spur.
Der Flow wurde im Debugmodus gestartet und ist morgen Früh sicher fertig. Da unveränderte Einstellungen wird er nicht ohne Fehler durchlaufen.
RunID: b84e80ee-5a1b-11e9-8d39-901b0ea49fee
Support-Benutzer: Leider ist unser Account Inhaber aktuell nicht greifbar, jedoch sollte ein Support-Benutzer existieren.
Vielen Dank für die Hilfe!
Der Flow wurde im Debugmodus gestartet und ist morgen Früh sicher fertig. Da unveränderte Einstellungen wird er nicht ohne Fehler durchlaufen.
RunID: b84e80ee-5a1b-11e9-8d39-901b0ea49fee
Support-Benutzer: Leider ist unser Account Inhaber aktuell nicht greifbar, jedoch sollte ein Support-Benutzer existieren.
Vielen Dank für die Hilfe!
Der Run b84e80ee-5a1b-11e9-8d39-901b0ea49fee scheint diesmal ohne Fehler durchgelaufen zu sein. Wir müssen somit auf den nächsten Durchlauf mit Fehler warten.
OK, das Problem tritt nicht auf, wenn die Zielfelder schon den entsprechenden Wert beinhalten. Da der Flow das zweite mal lief, wurden scheinbar fast keine Änderungen ausgeführt.
Bei einem weiteren Versuch konnte wieder ein Fehler provoziert werden:
RunID: c8fdd25e-5ac7-11e9-8d39-901b0ea49fee
