Data: destroyRecord regression in 2.13.x

Created on 24 May 2017  路  10Comments  路  Source: emberjs/data

I started experiencing a regression after upgrading to 2.13.x from 2.12.2. The error happens when calling destroyRecord, then later querying records. Here is a test case route that reproduces the issue for me:

export default Ember.Route.extend({
  model() {
    this.store.findRecord('my-model', '123')
      .then(m => m.destroyRecord())
      .then(() => this.store.query('my-model', {}));
  }
});

The gotcha in our system is that the DELETE handler does not immediately delete the record, but marks the record for deletion. So it will still be returned in query calls until it's finished being deleted.

The error that I am getting in 2.13.1 is

Attempted to handle event `pushedData` on <my-model:123> while in state root.deleted.saved. 

Error
    at InternalModel._unhandledEvent (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:140691:13)
    at InternalModel.send (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:140560:14)
    at InternalModel.pushedData (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:140502:12)
    at InternalModel.setupData (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:140465:12)
    at Class._load (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:148474:21)
    at Class._pushInternalModel (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:148836:32)
    at http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:148779:39
    at Backburner.run (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:17614:23)
    at Backburner.join (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:17640:23)
    at Class._push (http://localhost:4200/ui/assets/vendor-541f5b0fb0f07999ce5d23075731eb0c.js:148763:52)

Most helpful comment

I believe we are experiencing similar behavior:

  • destroyRecord is called, succeeds
  • the query then refreshes, which returns an instance of the same record
  • Attempted to handle event pushedData on <user:280883> while in state root.deleted.saved exception is thrown

In our case, adding an model.unloadRecord() before the query refreshes solves the problem.

All 10 comments

I wound up having to change our UI to send a manual DELETE request, rather than use the destroyRecord api.

Any progress here on a fix? This issue has gotten to be a big problem while trying to upgrade from 2.13.x to 2.15.x (currently we're locked on ED 2.12.x while on Ember 2.13.x, though having such a large disparity onward - 2.12 ED and 2.15 Ember - feels misguided, so this is a blocker for us on upgrading Ember).

@yads your solution is weird, destroyRecord sends a delete request, and then on success it unloads the record. I'm unsure how that differs from what you've done, but maybe that also points to where we need to look to fix.

As far as I can tell, committing a record as being deleted also marks it in the store as having state 'root.deleted.saved'. When the store sees it again via a reload query, it seems to then have an issue with this. Manually sending a DELETE request, does not mark it in the store as having been deleted.

Oh, so you mean not via deleteRecord. Question, why are you reloading deleted records, is this the same as #5237 maybe?

I'm following this because we also ran into a similar issue. I think is because when you unload a record it no longer ends up in root.deleted.saved, it's just root.loaded.saved now. See: https://github.com/emberjs/data/issues/4918

Edit: Actually @yads never said if he unloads the record or just leaves it alone, so maybe I preemptively assumed that.

@runspired it looks like that issue you referenced is essentially the same. The reason we are reloading the record is because sending the DELETE request merely starts the deletion process, which can take some time depending on the entity being deleted. So we want to reload the data to make sure the user is seeing the new status of the entity.

I believe we are experiencing similar behavior:

  • destroyRecord is called, succeeds
  • the query then refreshes, which returns an instance of the same record
  • Attempted to handle event pushedData on <user:280883> while in state root.deleted.saved exception is thrown

In our case, adding an model.unloadRecord() before the query refreshes solves the problem.

If @thec0keman's suggestion doesn't work, I did something along the lines of what is discussed in #4972.

this.store._removeFromIdMap(your-problem-model._internalModel);

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stefanpenner picture stefanpenner  路  4Comments

Robdel12 picture Robdel12  路  5Comments

toobulkeh picture toobulkeh  路  3Comments

graham-sportsmgmt picture graham-sportsmgmt  路  3Comments

bekicot picture bekicot  路  4Comments