Inexplicable model.hasInverseFor is not a function

[btrude]

I'm really not sure what is going on with this issue, I'd like to be able to reproduce it outside of the specific context in which our tests are running but it's not immediately reproducible with boilerplate.

We have in our app an employee model with a user attribute that belongsTo a user model. When we expand a dropdown and enter search terms we expect to receive a list of employees. Stepping through mirage's set method and inspecting the various model instances shows the following:

Clearly the last model before the error occurs is not the correct type and thus doesn't have hasInverseFor but I can't understand why that would be the case. I am creating the employee record in the following way and like I mentioned above mirage is able to handle the response to that initial request to /employees in order to populate the dropdown in the first place:

const user = this.server.create('user');
this.server.create('employee', { user });

Removing this check from mirage allows the test to pass successfully so I'm somewhat inclined to say that this an issue with mirage itself. Any help would be very much appreciated. Thanks!

[samselikoff]

Sorry about the delayed response! I'm behind on issues a bit due to some consulting/training work.

A reproduction would definitely be the most helpful thing here, even if you can't boil it down 100%.

The last model you log shows things like InternalModel, which I believe means this might be an Ember Data model... do you happen to be doing something like passing your server.create('user') into an Ember component?

[btrude]

The last model you log shows things like InternalModel, which I believe means this might be an Ember Data model... do you happen to be doing something like passing your server.create('user') into an Ember component?

Yeah, that's exactly what we're doing when the issue occurs. I will work on trying to get it reproduced soon... thanks for your help!

[samselikoff]

In that case you might want to give this a read:

https://www.ember-cli-mirage.com/docs/testing/integration-and-unit-tests#creating-ember-data-models-on-the-client-with-mirage

You shouldn't be passing Mirage models into Ember code. Let me know if that guide makes sense.

[btrude]

In that case you might want to give this a read:

https://www.ember-cli-mirage.com/docs/testing/integration-and-unit-tests#creating-ember-data-models-on-the-client-with-mirage

You shouldn't be passing Mirage models into Ember code. Let me know if that guide makes sense.

Thankfully we are aware of and already following that guide but I'll double-check to make sure we haven't missed something crucial. In the case of this problem we aren't setting the mirage model as a property for the component, but rather the component makes a request to the store to retrieve a list of "employees" on its own. Its in the course of populating the list that the error is thrown.

[samselikoff]

Interesting, ya somehow it seems like an ED model instance is getting set as an attr on a Mirage model, which should be impossible if you go through the HTTP barrier. If you can't figure it out in your code I'd be happy to take a look at a reproduction. Good luck!