-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add logging that hints at relationship bug ≥ ED3.5 #243
Conversation
I think I tracked it down to ember-data not clearing all its caches in If I replace But this is just my preliminary results, I want to look a bit further into this issue. |
oh wow, nice find, thanks for digging into this! |
FWIW, this problem also appears intermittent. For example, if I run |
I think I found the problem, or at least a work-around. Here we are calling |
The test labeled "creating an associated record stores a reference to it in the parent" was failing intermittently when run with other tests under conditions "dont save hasMany" and "sync". This problem appears to be caused by the test logic not waiting for `store.unloadAll()` to complete. The Ember Data API docs state that this function schedules its work to be done during the next run loop so we wait for an additional cycle after calling it. See also: * https://api.emberjs.com/ember-data/3.14/classes/Store/methods/unloadAll?anchor=unloadAll * pouchdb-community#242 * pouchdb-community#243
The test labeled "creating an associated record stores a reference to it in the parent" was failing intermittently when run with other tests under conditions "dont save hasMany" and "sync". This problem appears to be caused by the test logic not waiting for `store.unloadAll()` to complete. The Ember Data API docs state that this function schedules its work to be done during the next run loop. However, instead of adding a delay and making assumptions about this, we wrap calls to this function in `run` to ensure that it has finished before continuing. See also: * https://api.emberjs.com/ember-data/3.14/classes/Store/methods/unloadAll?anchor=unloadAll * pouchdb-community#242 * pouchdb-community#243
The test labeled "creating an associated record stores a reference to it in the parent" was failing intermittently when run with other tests under conditions "dont save hasMany" and "sync". This problem appears to be caused by the test logic not waiting for `store.unloadAll()` to complete. The Ember Data API docs state that this function schedules its work to be done during the next run loop. However, instead of adding a delay and making assumptions about this, we wrap calls to this function in `run` to ensure that it has finished before continuing. See also: * https://api.emberjs.com/ember-data/3.14/classes/Store/methods/unloadAll?anchor=unloadAll * pouchdb-community#242 * pouchdb-community#243
The test labeled "creating an associated record stores a reference to it in the parent" was failing intermittently when run with other tests under conditions "dont save hasMany" and "sync". This problem appears to be caused by the test logic not waiting for `store.unloadAll()` to complete. The Ember Data API docs state that this function schedules its work to be done during the next run loop. However, instead of adding a delay and making assumptions about this, we wrap calls to this function in `run` to ensure that it has finished before continuing. See also: * https://api.emberjs.com/ember-data/3.14/classes/Store/methods/unloadAll?anchor=unloadAll * pouchdb-community#242 * pouchdb-community#243
The test labeled "creating an associated record stores a reference to it in the parent" was failing intermittently with the recently added ember LTS versions (e.g. 3.4) when run with other tests under conditions "dont save hasMany" and "sync". This problem appears to be caused by the test logic not waiting for `store.unloadAll()` to complete. The Ember Data API docs state that this function schedules its work to be done during the next run loop, so this commit wraps these calls with `Ember.run` to ensure that it finishes before continuing. See also: * https://api.emberjs.com/ember-data/3.14/classes/Store/methods/unloadAll?anchor=unloadAll * pouchdb-community#242 * pouchdb-community#243
The test labeled "creating an associated record stores a reference to it in the parent" was failing intermittently with the recently added ember LTS versions (e.g. 3.4) when run with other tests under conditions "dont save hasMany" and "sync". This problem appears to be caused by the test logic not waiting for `store.unloadAll()` to complete. The Ember Data API docs state that this function schedules its work to be done during the next run loop, so this commit wraps these calls with `Ember.run` to ensure that it finishes before continuing. See also: * https://api.emberjs.com/ember-data/3.14/classes/Store/methods/unloadAll?anchor=unloadAll * pouchdb-community#242 * pouchdb-community#243
The test labeled "creating an associated record stores a reference to it in the parent" was failing intermittently with the recently added ember LTS versions (e.g. 3.4) when run with other tests under conditions "dont save hasMany" and "sync". This problem appears to be caused by the test logic not waiting for `store.unloadAll()` to complete. The Ember Data API docs state that this function schedules its work to be done during the next run loop, so this commit wraps these calls with `Ember.run` to ensure that it finishes before continuing. See also: * https://api.emberjs.com/ember-data/3.14/classes/Store/methods/unloadAll?anchor=unloadAll * pouchdb-community#242 * pouchdb-community#243
This isn’t a change I think should actually be merged, but it helps reveal what’s causing this test failure start with Ember Data 3.5.
I feel like I have insufficient knowledge of how the internals of RecordData etc work to understand what’s happening and fix it. But you can see from the
console.log
statements that there are two copies of the related model being stored; one seems maybe-deleted but still hanging around?The actual
ingredients
returned later in the test have the same id:This is only happening when
sync
is false andsaveHasMany
is false. I suppose there could be a hack that filters duplicate records out of ahasMany
fetch but that seems less than desirable.