Bug #12
openConfirm that "deletions first" is best, for Rattail -> Rattail datasync
0%
Description
The normal Rattail -> Rattail datasync behavior is pretty solid but here and there an edge case comes up. In particular it's possible for certain types of records to be effectively "moved" in an external system. When this happens and it's synced to Rattail, the latter doesn't really consider it a move; rather it must delete the old record and then create the new one.
Traditional behavior for datasync has been to always process new+dirty records first, deleted last. I feel like there was a reason for that but not sure.
Some time ago (in 3c46e2bb) a config flag was added, which causes the behavior to reverse - i.e. deleted first, new+dirty last. The logic was intended to tweak Rattail -> Rattail datasync specifically; however it's implemented in the Rattail "watcher" so theoretically it could also affect Rattail -> "X" (any other system).
Anyway, just wanted to document here, that ever since turning on the config flag, and using "new" behavior for one particular multi-store setup, I don't think I've ever had another problem there. And today, the problem came up for a different multi-store setup; I will turn on the flag there as well.
So if much time goes by and still no issues at either place, then probably the config flag should default to ON so we avoid the problem going forward.
No data to display