Background:
I am using Sync which as you know uses DataStack under the hood.
On our app if a user toggles a favorite button quickly it breaks and stops toggling.
This favoriting mechanism involves creating a disposableContext from DataStack to create a favorite object. This object is disposable context never has save called on it and is a temporary object that should not be saved. The disposable object is then used to form a request to the server where it is then discarded and the response is parsed in Sync to be stored in CoreData.
After some investigation I tracked down the issue all the way down in DATAStack. For some reason "newDisposableMainContextWillSave(:)" is being triggered on the background context being created in Sync to map the JSON into CoreData. Even though that observer is only being set on a disposable context it somehow is being tied to the save method on the background context in Sync. Even more confusingly I observed the object id's for the disposable context and the background context and they are unique per context and consistent from when they are created to when the newDisposableMainContextWillSave(:) is called. It is in fact the background context being reset in newDisposableMainContextWillSave.
With all the above said, I have tried various ways to reproduce the issue in unit tests with no success. I have tired created a test in my own project, sync, and DATAStack but no matter the result it the test succeeds.
I am hoping we can get this fix into DATAStack and propagate this up to Sync since the changes are minimal and reflect what should be happening any way. Essentially the change is that the only context that should be reset on save is a disposable one.
@3lvis If you have any insight to why this may be happening I would be more than happy to try to write a test to reproduce it but as of now like stated above I have had no success.
Background: I am using Sync which as you know uses DataStack under the hood.
On our app if a user toggles a favorite button quickly it breaks and stops toggling.
This favoriting mechanism involves creating a disposableContext from DataStack to create a favorite object. This object is disposable context never has save called on it and is a temporary object that should not be saved. The disposable object is then used to form a request to the server where it is then discarded and the response is parsed in Sync to be stored in CoreData.
After some investigation I tracked down the issue all the way down in DATAStack. For some reason "newDisposableMainContextWillSave(:)" is being triggered on the background context being created in Sync to map the JSON into CoreData. Even though that observer is only being set on a disposable context it somehow is being tied to the save method on the background context in Sync. Even more confusingly I observed the object id's for the disposable context and the background context and they are unique per context and consistent from when they are created to when the newDisposableMainContextWillSave(:) is called. It is in fact the background context being reset in newDisposableMainContextWillSave.
With all the above said, I have tried various ways to reproduce the issue in unit tests with no success. I have tired created a test in my own project, sync, and DATAStack but no matter the result it the test succeeds.
I am hoping we can get this fix into DATAStack and propagate this up to Sync since the changes are minimal and reflect what should be happening any way. Essentially the change is that the only context that should be reset on save is a disposable one.
@3lvis If you have any insight to why this may be happening I would be more than happy to try to write a test to reproduce it but as of now like stated above I have had no success.