CODEWITHSUNDEEP
ember.jsember-dataember-cli
RyanHirsch
RyanHirsch

Reputation: 1847

Acceptance tests failing due to record inFlight with ember-data 1.13.4

I've just updated ember-data from 1.0-beta-18 to 1.13.4 and fixed all issues except this one that occurs during my acceptance tests when I try to destroy the application in my afterEach.

Error: Assertion Failed: You can only unload a record which is not inFlight. `<frontend@model:user::ember2881:null>`
    at new Error (native)
    at Error.EmberError (http://192.168.56.101:4200/assets/vendor.js:25627:21)
    at Object._emberMetalCore.default.assert (http://192.168.56.101:4200/assets/vendor.js:15879:13)
    at Object.ember$data$lib$system$model$states$$assertAgainstUnloadRecord [as unloadRecord] (http://192.168.56.101:4200/assets/vendor.js:80625:13)
    at InternalModel.ember$data$lib$system$model$internal$model$$InternalModel.send (http://192.168.56.101:4200/assets/vendor.js:82563:34)
    at InternalModel.ember$data$lib$system$model$internal$model$$InternalModel.unloadRecord (http://192.168.56.101:4200/assets/vendor.js:82441:14)
    at ember$data$lib$system$store$$Service.extend.unloadAll (http://192.168.56.101:4200/assets/vendor.js:84142:20)
    at Array.forEach (native)
    at ember$data$lib$system$store$$Service.extend.unloadAll (http://192.168.56.101:4200/assets/vendor.js:84133:48)
    at ember$data$lib$system$store$$Service.extend.willDestroy (http://192.168.56.101:4200/assets/vendor.js:85034:14)

When I deactivate a route in the application I do a user.save() which causes a xhr to go out, and is triggering this failure on the application destroy. Removing the user.save(). I have tried updating to the latest ember-cli-qunit and ember-qunit with no luck.

My afterEach looks like the following -

afterEach: function () {
    Ember.run(application, 'destroy');
    ajaxMock.shutdown();
}

Prior to the upgrade this was not an issue. How can I fix or work around this issue?

Upvotes: 3

Views: 1090

Answers (1)

Sam Selikoff
Sam Selikoff

Reputation: 12694

We ran into something similar. We had actually defined a destroy method on one of our objects (a session service), inadvertently overriding Ember.Object's destroy. Renaming this to something else (terminate in our case) fixed the issue.

Upvotes: 0

Related Questions