Hallo zusammen,
ich habe ein sehr spezielles, aber reproduzierbares Problem mit dem JTL-WooCommerce-Connector, das ich hiermit zur Diskussion und als möglichen Bug-Report stelle.
Problem:
Neue Bestellungen werden nicht sofort, sondern erst mit großer Verzögerung im Connector-Pull erkannt bzw. teilweise gar nicht synchronisiert. Das trotz korrektem Status und aktivem Worker.
AND p.post_date < DATE_SUB(NOW(), INTERVAL {$delay} SECOND)
Das Problem ergibt sich daraus, dass:
p.post_date > NOW()
=> Die Order wird nicht als pull-fähig erkannt, obwohl sie korrekt vorhanden ist.
Lösung:
Die Abfrage sollte statt post_date die GMT-Spalte und UTC_TIMESTAMP() verwenden:
AKTUELL: p.post_date < DATE_SUB(NOW(), INTERVAL {$delay} SECOND)
MEINE ÄNDERUNG: p.post_date_gmt < DATE_SUB(UTC_TIMESTAMP(), INTERVAL {$delay} SECOND)
Zusätzlich muss der optionale „since“-Zeitparameter in UTC umgerechnet werden, z. B. mit get_gmt_from_date().
Ich habe das im Code entsprechend angepasst und damit das Problem (für mich) gelöst.
Beweis:
Ist dieser SQL-Zeitfilter so gewollt? Sollte der Connector nicht immer UTC-basiert arbeiten, um globale Zeitkonflikte zu verhindern? Gibt es offiziell bereits eine Anpassung oder Planung dazu?
Vielen Dank für euer Feedback!
ich habe ein sehr spezielles, aber reproduzierbares Problem mit dem JTL-WooCommerce-Connector, das ich hiermit zur Diskussion und als möglichen Bug-Report stelle.
Problem:
Neue Bestellungen werden nicht sofort, sondern erst mit großer Verzögerung im Connector-Pull erkannt bzw. teilweise gar nicht synchronisiert. Das trotz korrektem Status und aktivem Worker.
Ursache (technisch identifiziert):
Im Code des Connectors (Trait CustomerOrderTrait::customerOrderPull()) wird folgender SQL-Filter genutzt:AND p.post_date < DATE_SUB(NOW(), INTERVAL {$delay} SECOND)
Das Problem ergibt sich daraus, dass:
- post_date die lokale WordPress-Zeit speichert, und
- NOW() die MySQL-Serverzeit verwendet, die typischerweise in UTC läuft.
p.post_date > NOW()
=> Die Order wird nicht als pull-fähig erkannt, obwohl sie korrekt vorhanden ist.
Lösung:
Die Abfrage sollte statt post_date die GMT-Spalte und UTC_TIMESTAMP() verwenden:
AKTUELL: p.post_date < DATE_SUB(NOW(), INTERVAL {$delay} SECOND)
MEINE ÄNDERUNG: p.post_date_gmt < DATE_SUB(UTC_TIMESTAMP(), INTERVAL {$delay} SECOND)
Zusätzlich muss der optionale „since“-Zeitparameter in UTC umgerechnet werden, z. B. mit get_gmt_from_date().
Ich habe das im Code entsprechend angepasst und damit das Problem (für mich) gelöst.
Beweis:
- Logs zeigen, dass Orders mit post_date in der Zukunft (lokal vs. UTC) durch den Filter herausgefiltert werden.
- Nach Patch erscheinen sie sofort im Pull.
Ist dieser SQL-Zeitfilter so gewollt? Sollte der Connector nicht immer UTC-basiert arbeiten, um globale Zeitkonflikte zu verhindern? Gibt es offiziell bereits eine Anpassung oder Planung dazu?
Vielen Dank für euer Feedback!