This occurs on the current LTS, and can lead to loss of user data.
Some more background on this:
One of our services had a temporary outage. As a result, a model failed to load. I noticed afterwards that some columns that shouldn't have been null were marked as null. After some investigation, I discovered that the partial outage caused ember-data to save the model with the foreign key set to null, which caused some data loss.
Thankfully this only occurred to our internal models, but the likelihood of this happening again and possibly messing up our users data is high (in the event of another incident).
@nlincoln thanks for the report and the reproduction, I'll dig into this as soon as I can.
@NLincoln my understanding is that this is probably related to some regressions caused by two major new features: improved dematerialization and lazy relationships. The data team has been knocking down these regressions, so thanks for the report, especially since this regression could cause data loss.
After investigating, I don't think this is a regression, and very possibly it's something end user's serializers would need to account for on their own. If a related record is in a loading or error state, it's unlikely we could serialize it correctly much of the time.
I'm debating whether we should error here or pretend the relationship doesn't exist at all (don't serialize vs null id)
Discussed this at the team meeting, not sure I fully agree with the previous answer, but assigned it to myself to investigate.
Might be worth pairing with @snewcomer on this as part of fixing some issues similar to this that have open PRs for failing tests
Most helpful comment
@NLincoln my understanding is that this is probably related to some regressions caused by two major new features: improved dematerialization and lazy relationships. The data team has been knocking down these regressions, so thanks for the report, especially since this regression could cause data loss.