emberjs
belongsTo property has no id after GET request is rejected
Description
// RESTAdapter is used
export default class MyModel extends Model {
@belongsTo('foo', { async: true }) foo;
}
const myModel = loadMyModel(); // myModel is loaded, myModel.foo is not loaded.
myModel.belongsTo('foo').id() // 99
Ember.get(myModel, 'foo.id'); // logs 99 and initiates 'foo' loading
...
// Backend rejects the request `/api/foos/99` with 403.
...
Ember.get(myModel, 'foo.id'); // logs undefined <----------------- expected 99.
myModel.belongsTo('foo').id() // 99
I'm not sure if it's a bug, but at least it's very strange.
Versions
ember-data 3.24.0
@nag5000 Is this something you would be interested in pushing a PR with a test indicating your issue? That way we can prioritize a fix.
@nag5000 Thank you for the test. So this isn't expected from the point of view of a the ember primitives - ObjectProxy and PromiseProxyMixin. However, in the comments in the code below...
when a load fails, in this case we need to make sure that we aren't proxying to destroyed content
https://github.com/emberjs/data/blob/9889ebbd4eec162dba17bb00126ee71e49d04bce/packages/store/addon/-private/system/model/internal-model.ts#L1396-L1407
This is unavoidable. Unless you are able to convert to non async relationships. Seems this issues occurs if we were to revert null'ing out the content of the proxy after an error.
https://github.com/emberjs/data/issues/5814
Let me know if you have any other questions or concerns. Will close the issue for now.
Yeah, I see. To be honest, it still seems odd.., but, yeah, I understand it's by design, and it doesn't make sense to make a lot of changes to the InternalModel to fix this.
To clarify things a bit, this kinda "inconsistency" in a real-world application can lead to some oddities when the id of an async belongsTo relationship is used as a dependency key in a computed property, or as a model in LinkTo <LinkTo @route="a" @model={{this.myModel.foo.id}}>{{this.myModel.foo.title}}</LinkTo>. It's not very critical, but sometimes you have to reckon with it.
I'm not sure this should be closed, so I'm reopening it. While the current behavior is indeed intended, it's open for discussion whether there isn't a better way to handle this case (where we know the id, but for unknown reasons the API request is failing). Potentially we can enter a recoverable error state here.
