Open eodb opened 11 months ago
separate from whether there is a bug here, the payload setup here isn't describing the doc-page entries relationship in a valid way. The invalid setup likely contributes to the observed issue by putting the relationship into an invalid state, from which point the later behaviors become less well defined.
Hi @runspired, Finally found the time to look into this again (our major release is out..). I couldn't figure our immediately what was wrong in the setup, so instead I tried to extend one of the exiting tests from the ember-data testsuite since the setup was almost similar. I've made a PR (https://github.com/emberjs/data/pull/9326) that will make it clear I guess. Repeating the scenario twice (i.e. setting the belongsTo relation to null) generates the same error. Hope this helps to figure this one out.
Getting same error in an acceptance test after upgrading.
Error: Cannot remove a resource that is not present
at eval (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:374:633)
at _removeRemote (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:374:694)
at removeFromInverse (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:298:1355)
at addToInverse (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:294:1667)
at eval (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:275:120)
at _compare (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:358:96)
at diffCollection (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:361:47)
at replaceRelatedRecordsRemote (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:272:79)
at replaceRelatedRecords (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:260:68)
at Graph.update (webpack://__ember_auto_import__/./node_modules/ember-data/node_modules/@ember-data/graph/dist/-private.js?:498:235)
ember-data: 5.3.8
Reproduction
It took some time to find a reproducible qunit test but here it is:
Description
Populate a "belongsTo" relationship with an inverse "hasMany", and clear it afterwards. This works fine the first time. (see 1st iteration in comment) The second time however, running the same scenario by submitting the same payload(s), an assertion error occurs: "Cannot remove a resource that is not present". (see 2nd iteration in comment)
Expected: the same result the 2nd time the payloads are submitted.
Unexpected is also that when the "docPage.entries" relationship is simply accessed by reading the property, the test succeeds while this should have no effect. (to reproduce, uncomment the line after "NOTE: UNCOMMENT THE LINE BELOW..." in the test above)
Debugging the issue learned the following:
In the 2nd iteration of the scenario above, the docPage.entries relationship.localState = []. This causes the assert in the 2nd scenario when clearing the belongsTo relationship of the entry.docPage by updating the reverse relationship of docPage.entries in '_removeRemote', called from 'removeFromInverse' because localState is not null, but an empty array:
By reading the "docPage.entries" relationship, before the belongsTo relationship of the entry.docPage is cleared (UNCOMMENT THE LINE - in the test above), the docPage.entries relationship.localState is not empty and does contain the identifier, which can then be successfully removed when clearing the entry.docPage belongsTo relationship, passing the test.
Versions