Links related relationship on modelA nulls belongsTo on modelB

[DingoEatingFuzz]

Data Model

1. modelA has a hasMany('modelB')
2. modelB has a belongsTo('modelA')
3. modelB payload looks like this: model_a_id: 'model-a-1'
4. modelA payload does not include the set of modelB ids. Instead, it is related through a related link: /api/model-a/:id returns the model and /api/model-a/:id/model-b returns the set of related modelB.

Steps to reproduce

1. Find a modelB
2. Do not find the modelB's modelA
3. Find modelB's modelA independently
4. Observe that modelB.get('modelA') is a fulfilled promise with null for content

Expected result

modelB should maintain its relationship with modelA despite modelA being loaded with unknown IDs for its hasMany modelB.

Actual result

The relationship is null and the original ID from the payload is now lost.

Notes

This only happens in this order. If modelB's modelA is already loaded, it seems to be fine.

[pangratz]

Can you update this ember-twiddle so it demonstrates the issue you're having? That would help greatly track down the issue your having! Thanks!

[lolmaus]

I've filed a very similar issue: #5211, it's either related or duplicated. I've provided a reproduction twiddle.

[williamhector]

Here is a twiddle that I believe is the same issue as the OP:
https://ember-twiddle.com/2cf56ec2cd082d5c5a109e51993de730?openFiles=adapters.organisation.js%2C

The application route loads a given user, loads a given organisation, then loads the user's organisation (should be the same as the given org).
The organisation's users relationship (adminUsers) is never loaded, so while it might be related, I believe it's not a duplicate.

If you omit the "links" from the payload in adapters/organisation.js, the issue doesn't occur.
Or, if you call user.get('organisation') before store.findRecord('organisation', id) in routes/application.js then the issue doesn't occur.

[BryanCrotaz]

I can confirm this behaviour in a real world app

[BryanCrotaz]

I'm working on a PR

[BryanCrotaz]

I have a failing test based on @williamhector 's twiddle...
Inverse relationship must be null on the belongsto to break

[BryanCrotaz]

Found the problem - the payload data is cached until you read the relationship. Because you've not defined the inverse on one side, the second one is stomping on it - we need to keep the two relationships separate when defining the second end of the relationship.
Working on it

[BryanCrotaz]

Fixed in #5257

[bmac]

I believe this has been fixed by #5230. Feel free to reopen if it is still an issue.