belongsTo of a belongsTo not working under 2.14 beta

[mwpastore]

The following type of payload manipulation works in 2.12 and 2.13 but not 2.14-beta:

store.findRecord('product', 1, { include: 'type,type.group' }).then(product => {
  let typeRef = product.belongsTo('type'); // OK
  let typeId = type.id(); // OK
  let type = type.value(); // OK

  let groupRef = type.belongsTo('group'); // OK (or at least seems OK, but inverseInternalModel is null)
  let groupId = groupRef.id(); // null (not OK)
  let group = groupRef.value(); // null (not OK)

[stefanpenner]

@mwpastore mind submitting a PR with a failing test, this will very much help us look into this issue sooner.

[mwpastore]

@stefanpenner I can't reproduce it with a failing test, so that was an illuminating exercise.

I went back to my original problem, made the relationships sync, and used get() to walk them (bypassing the references API). That doesn't work, either, under 2.14-beta; I confirmed it works under 2.12 and 2.13. I thought maybe the problem is that I have a relationship key named type, so I renamed it and retested, with no change. I then noticed this error message in my console under 2.14-beta:

WARNING: You pushed a record of type 'product' with a relationship 'type' configured
         as 'async: false'. You've included a link but no primary data, this may be
         an error in your payload.

And confirmed it doesn't appear under 2.12 and 2.13. It seems to me that the linkage data and/or included relationships in the payload are being handled differently in 2.14-beta. I should add to my original problem description that my models look something like:

// app/models/product.js
export default DS.Model.extend({
  type: DS.belongsTo('product-type')
});

// app/models/product-type.js
export default DS.Model.extend({
  products: DS.hasMany(),
  group: DS.belongsTo('product-group')
});

// app/models/product-group.js
export default DS.Model.extend({
  types: DS.hasMany('product-type')
});

So I suspect the problem has something to do with the fact that my payload keys don't exactly match my types. Either my payload is fine and something is broken, or my payload is slightly off and ED is more strict than it was. The payload looks fine to me... any suggestions on where to go from here?

Payload

{
  "data": [
    {
      "type": "products",
      "id": "1",
      "attributes": {
        "name": "Product Photography",
        "sku": "000001",
        "unit-cost": "$39.99"
      },
      "links": {
        "self": "/api/v1/products/1"
      },
      "relationships": {
        "type": {
          "links": {
            "self": "/api/v1/products/1/relationships/type",
            "related": "/api/v1/products/1/type"
          },
          "data": {
            "type": "product-types",
            "id": "1"
          }
        }
      }
    }
  ],
  "jsonapi": {
    "version": "1.0"
  },
  "included": [
    {
      "type": "product-types",
      "id": "1",
      "attributes": {
        "name": "Product Photography",
        "product-variant-id": null,
        "unit-cost-delta": null
      },
      "links": {
        "self": "/api/v1/product-types/1"
      },
      "relationships": {
        "group": {
          "links": {
            "self": "/api/v1/product-types/1/relationships/group",
            "related": "/api/v1/product-types/1/group"
          },
          "data": {
            "type": "product-groups",
            "id": "1"
          }
        },
        "products": {
          "links": {
            "self": "/api/v1/product-types/1/relationships/products",
            "related": "/api/v1/product-types/1/products"
          }
        },
        "variants": {
          "links": {
            "self": "/api/v1/product-types/1/relationships/variants",
            "related": "/api/v1/product-types/1/variants"
          }
        }
      }
    },
    {
      "type": "product-groups",
      "id": "1",
      "attributes": {
        "name": "Product Photography"
      },
      "links": {
        "self": "/api/v1/product-groups/1"
      },
      "relationships": {
        "customer-product-categories": {
          "links": {
            "self": "/api/v1/product-groups/1/relationships/customer-product-categories",
            "related": "/api/v1/product-groups/1/customer-product-categories"
          }
        },
        "bulk-discount-schedules": {
          "links": {
            "self": "/api/v1/product-groups/1/relationships/bulk-discount-schedules",
            "related": "/api/v1/product-groups/1/bulk-discount-schedules"
          }
        },
        "types": {
          "links": {
            "self": "/api/v1/product-groups/1/relationships/types",
            "related": "/api/v1/product-groups/1/types"
          }
        }
      }
    }
  ]
}

[mwpastore]

@stefanpenner, cc: @runspired

An update:

My backend serializer sends relationship.links by default, but not relationship.data. However, if a relationship is included, it includes the links and the data for that relationship. You can see this in the payload above: type was included, as was type.group, so the data sections are present for those edges in addition to the included entities; cf. type.products and type.variants, where only the links sections are present.

This works fine in ED 1.13–2.13, but in 2.14+ the presence of the links causes ED to ignore(?) the data section and become unable to establish the linkages between these entities. Defining explicit inverses does not mitigate the issue. Forcing my backend serializer to never include links on these edges solves the above use case as well as related use cases I'm encountering; unfortunately, it breaks other use cases where ED needs the links to walk asynchronous edges.

(EDIT: Well, that's not quite the full story, either. Conditionally disabling links if data is present and establishing explicit inverses throughout my models does not completely solve the problem as I expected.)

Now that I have a better understanding of the issue, I will try once again to submit a PR with a failing test.

[stefanpenner]

Ya something seems off, it would be super useful if a failing test could be provided.

[sly7-7]

@stefanpenner seems like there is one here: https://github.com/emberjs/data/pull/5124/files

[stefanpenner]

if in-fact this is reproduced by #5124 then #5147 should fix this.

[mwpastore]

I'm going to express some cautious optimism here: This appears to be fixed under Ember 2.15.0 and ED 2.14.11. At least my app boots up, which it never has before under 2.14. I'll work with it a bit over the long weekend and provide another update next week.

[stefanpenner]

@mwpastore i'll reopen if you comment with further issues (and ideally a failing test case ;))