Add logging that hints at relationship bug ≥ ED3.5

[backspace]

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?

           [
              {
                "id": "29072F20-1883-0097-8660-51714430829F",
                "clientId": 2,
                "data": {}
              },
              {
                "id": "29072F20-1883-0097-8660-51714430829F",
                "data": {
                  "name": "pineapple",
                  "rev": "1-52f8d66785bec8cc48d5599314941d9e"
                }
              }
            ]

The actual ingredients returned later in the test have the same id:

            LOG: found ingredients: 29072F20-1883-0097-8660-51714430829F: pineapple,29072F20-1883-0097-8660-51714430829F: pineapple

This is only happening when sync is false and saveHasMany is false. I suppose there could be a hack that filters duplicate records out of a hasMany fetch but that seems less than desirable.

[jlami]

I think I tracked it down to ember-data not clearing all its caches in store.unloadAll().

https://github.com/emberjs/data/blob/24e69e2d14ece1e363da9b65e174b19f59f782ba/addon/-private/system/store.js#L2128-L2143

If I replace this._identityMap.clear(); with this._identityMap = new IdentityMap(); in that function the bug disappears. This might also give some insight into why it only breaks after other tests.

But this is just my preliminary results, I want to look a bit further into this issue.

[backspace]

oh wow, nice find, thanks for digging into this!

[jacobq]

FWIW, this problem also appears intermittent. For example, if I run ember test --server --filter="integration | adapter | basic crud ops > dont save hasMany" then ~30 tests get run, sometimes 1 fails (same as noted previously), but if I hit refresh to run again it seems to pass about 50% of the time. If I add > sync to that ~12 tests run and pass every time.

[jacobq]

I think I found the problem, or at least a work-around. Here we are calling store.unloadAll() as if it did its work immediately, but in fact it schedules it to be done on the next run loop. Adding promiseToRunLater(1) to the chain here before the call to findRecord makes the problem go away.