hasMany association with links causes backtracking re-render error

[rlivsey]

Running against Canary I'm getting the following error when a has many relationship with links is used in a template:

Assertion Failed: You modified "meeting.attendees" twice on <minutebase@model:meeting::ember1351:772c5e6e-aceb-11e6-ae79-770161ca087d> in a single render. It was rendered in "component:mb-pages/dashboard/meeting" and modified in "component:mb-pages/dashboard/meeting". This was unreliable and slow in Ember 1.x and is no longer supported. See https://github.com/emberjs/ember.js/issues/13948 for more details.
Error
    at assert (http://minutebase.dev:4202/assets/vendor.js:21770:13)
    at assert (http://minutebase.dev:4202/assets/vendor.js:33521:34)
    at Object.assertNotRendered (http://minutebase.dev:4202/assets/vendor.js:39296:11)
    at Object.propertyDidChange (http://minutebase.dev:4202/assets/vendor.js:37912:30)
    at Class.propertyDidChange (http://minutebase.dev:4202/assets/vendor.js:51064:19)
    at Class.notifyPropertyChange (http://minutebase.dev:4202/assets/vendor.js:51078:12)
    at InternalModel.notifyPropertyChange (http://minutebase.dev:4202/assets/vendor.js:140423:21)
    at ManyRelationship.updateLink (http://minutebase.dev:4202/assets/vendor.js:147451:19)
    at ManyRelationship.push (http://minutebase.dev:4202/assets/vendor.js:147529:16)
    at Relationships.get (http://minutebase.dev:4202/assets/vendor.js:146885:24)

Looks like updateLink is notifying property change and causing Glimmer to re-evaluate the relationship and so it explodes.

I narrowed it down to when #4821 was merged, which makes sense as I assume that the links was previously resolved in advance but not happens when it's accessed.

Here's a twiddle which will hopefully demonstrate it, I can't get it working against ember-data canary as I get an error of "No application initializer named 'store'"

[rlivsey]

@stefanpenner @runspired here ya go! Let me know if there's any more info that would be useful.

[BryanCrotaz]

I can reproduce this on 2.14, but not on 2.13.2. My json-api data doesn't have links, just data and includes

[sly7-7]

I think #5017 is the same

[buschtoens]

In #5023 I created a working example app demonstrating the problem.

[roomle-build]

Same problem here! Ember Data 2.13.2 does not suffer from this problem. Ember Data 2.14.2 causes a rerender as described by @rlivsey in updateLink

[tsteuwer]

We are having the exact same issue in all of our applications when it auto-updated to 2.14.*. We've reverted back to 2.13.1 and it fixed the issue.

[ctcpip]

This is happening for me when accessing a related model property in a template: {{model.relatedModel.property}}

[eriktrom]

Same issue, i upgraded an app this afternoon (for a client, i dont know tons about it) but i do know that upgrading from ember-data@2.13.x -> ember-data@2.14 caused 8 re-render errors in 2 templates where the templates did async relationship lookups, aka, asyncFoo.asyncSomething && asyncSomething.asyncFoo

i put them in a gist, with the errors(too long for here) https://gist.github.com/eriktrom/6174fbabf1d6bf35cd65ee6ea9f34266

just fyi

(i dont know enough about the app to give further context, it was an afternoon upgrade)

Note: its not using json-api, so links are not the issue, it actually uses "active-model-adapter": "2.1.1" addon (which is older i know, but not complicated, and based on rest adapter IIRC)

[SphtKr]

Also having the same issue with a brand-new and incredibly simple app. Can't do things the guides say you can, like:

<ul>
  {{#each blogPost.comments as |comment|}}
    <li>{{comment.id}}</li>
  {{/each}}
</ul>

I will try rolling back to 2.13, but based on the description above I'm pretty confident that will do it. I'm using JSONAPI, but this happens whether it's async, hasMany or belongsTo, basically I can't access any model relationships in template code without throwing an exception.

[vasa-chi]

Can confirm (on versions after 2.12.2). I have a simple route:

import Ember from "ember";

export default Ember.Route.extend({
  model(params) {
    return this.store.findRecord("blogs", params.blog_id, {
      include: "comments",
    });
  },
});

and a template:

<ul>
  {{#each model.comments as |comment|}}
    <li>{{comment.body}}</li>
  {{/each}}
</ul>

And the exception is thrown on model.comments render.

blogpost model

import DS from "ember-data";

export default DS.Model.extend({
  name: DS.attr(),

  reports: DS.hasMany("comment"),
});

comment model

import DS from "ember-data";

export default DS.Model.extend({
  text: DS.attr(),

  database: DS.belongsTo("blogpost"),
});

The JSONAPI response for include query

{
  "data": {
    "attributes": {
      "name": "whatever"
    }, 
    "id": 1, 
    "links": {
      "self": "/api/blogposts/1"
    }, 
    "relationships": {
      "reports": {
        "data": [
          {
            "id": "1", 
            "type": "comments"
          }, 
          {
            "id": "2", 
            "type": "comments"
          }
        ], 
        "links": {
          "related": "/api/blogposts/1/comments"
        }
      }
    }, 
    "type": "blogposts"
  }, 
  "included": [
    {
      "attributes": {
        "text": "blablabla"
      }, 
      "id": 1, 
      "links": {
        "self": "/api/comments/1"
      }, 
      "relationships": {
        "blogpost": {
          "links": {
            "related": "/api/blogposts/1"
          }
        }
      }, 
      "type": "blogposts"
    },
    {
      "attributes": {
        "text": "foobar"
      }, 
      "id": 2, 
      "links": {
        "self": "/api/comments/2"
      }, 
      "relationships": {
        "blogpost": {
          "links": {
            "related": "/api/blogposts/1"
          }
        }
      }, 
      "type": "blogposts"
    }, 
  ], 
  "links": {
    "self": "/api/blogposts/1"
  }
}

[buschtoens]

Can confirm (on versions after 2.12.2). I have a simple route:

@vasa-chi Are you sure about that version? Everyone in here only has problems from 2.14.0 onwards.

[vasa-chi]

@buschtoens sorry, I meant on versions after 2.12.2. 2.12.2 was OK for me.
But I've re-checked now, and ~2.13.0 is also OK. So yeah, the problem is on ~2.14.0

[SphtKr]

Well, I'm still getting it after having rolled back all the way to 2.13.0 ... which makes me wonder if I'm doing something else wrong, but if so I can't see what. The application is so early and so simple--there is nowhere that I'm modifying the model objects--period--except for traversing to async relationship properties. All I have to do is access dataset.records and it fails with the double-modify error. I.e., here's my route:

import Ember from 'ember';
export default Ember.Route.extend({
  model() {
    return this.get('store').findAll('dataset');
  }
});

And here's my template:

<h2>Datasets</h2>
<ul>
  {{#each model as |dataset|}}
    <li>{{#link-to "datasets.records" dataset}}{{dataset.title}}{{/link-to}}</li>
  {{/each}}
</ul>
{{outlet}}

Which works fine... But if I change the link-to like so:

{{#link-to "datasets.records" dataset.records}}{{dataset.title}}{{/link-to}}

I get:

Assertion Failed: You modified "records" twice on <frontend@model:dataset::ember301:ds1> in a single render. It was rendered in "component:link-to" and modified in "component:link-to".

And that's on 2.13.0. I tried to make an ember-twiddle, but I don't see how to make one with a JSONAPI data source or even fixtures...could be missing it.

[buschtoens]

@SphtKr you can use the Mirage boilerplate for that: https://ember-twiddle.com/eedfd390d8394d54d5bfd0ed988a5d0f

[tschoartschi]

Is this a bug within Ember-Data or is this an issue with our code? And if it is an issue with our code, how can we fix it? For me it is really hard to spot the problem. Sometimes it obvious but sometimes it is very hidden. Especially in a big application like ours. We develop with Ember since more than three years and so our code base is quite big.

[beerlington]

@tschoartschi most likely a bug if you're not using anything that's private or undocumented. You can just use 2.13 until it's resolved.

[RGL9032]

This a prime example of how horrible things have become in ember-data. @rlivsey reported this issue 4 months ago when it first hit in Canary. Nothing was done, this mishap went to Beta. People continued to report it, nothing was done, it shipped. Ember folks always say "test your apps on beta/canary and report issues". A lot of good that did.

[fivetanley]

@RGL9032 A lot of hours (both in and out of work), between various members of the data and core team, have been spent fixing issues with the branch that eventually became 2.14.

Ember folks always say "test your apps on beta/canary and report issues". A lot of good that did.

There are many issues we don't know about, and @rlivsey has reported (and/or fixed) many of them! We do appreciate any contributions when people report issues.

While we haven't gotten to this issue yet, we are working on fixing it. I'm sorry we let this breaking behavior slip through, but testing on beta and canary has prevented hundreds of bugs/regressions from getting out into the wild.

You can always pin to a previous release if this change breaks your app. We'll be backporting fixes to 2.14 as we can as well.

Ember is and always has been on a volunteer basis. Everyone in this thread has contributed useful debugging info, or constructive questions. I'm not sure what you wanted to get out of posting comments like this, but it doesn't help us debug or prioritize issues.