Ember.js: Ember 3.0 Regression, attribute value not being serialized

[atomkirk]

This seems like this would be an ember-data issue, but it starts happening only if i change ember-source from 2.18 -> 3.0. If I leave ember-data and ember-cli at 3.0 or 3.1, but have ember source at 2.18, it also works.

Here's the issue:

You can see that the first line item on the model has blah as the value of notes as save() is being called.

But the payload to the server looks like this: (note notes: "")

{
  "title": "Invoice Title",
  "po_number": "PO-3",
  "currency_code": "USD",
  "notes": "",
  "terms": "",
  "number": "GHANGI-0001",
  "date": "2018-06-30",
  "cloud_files": [],
  "line_items": [
    {
      "name": "test1",
      "notes": "",
      "quantity": 1,
      "rate": 3,
      "type": "time-entry",
      "discount": "0.00",
      "order": 1
    }
  ],
  "account_id": "5",
  "customer_id": "8"
}

Here is my deps:

  "devDependencies": {
    "broccoli-asset-rev": "^2.4.5",
    "ember-ajax": "^3.0.0",
    "ember-cli": "~3.1.3",
    "ember-cli-app-version": "^3.0.0",
    "ember-cli-babel": "^6.6.0",
    "ember-cli-dependency-checker": "^2.0.0",
    "ember-cli-eslint": "^4.2.1",
    "ember-cli-htmlbars": "^2.0.1",
    "ember-cli-htmlbars-inline-precompile": "^1.0.0",
    "ember-cli-inject-live-reload": "^1.4.1",
    "ember-cli-qunit": "^4.1.1",
    "ember-cli-shims": "^1.2.0",
    "ember-cli-sri": "^2.1.0",
    "ember-cli-uglify": "^2.0.0",
    "ember-data": "~3.1.0",
    "ember-export-application-global": "^2.0.0",
    "ember-load-initializers": "^1.0.0",
    "ember-maybe-import-regenerator": "^0.1.6",
    "ember-resolver": "^4.0.0",
    "ember-source": "~3.1.0", // <-------------- change only this to ~2.18.0 and it works again
    "ember-welcome-page": "^3.0.0",
    "eslint-plugin-ember": "^5.0.0",
    "loader.js": "^4.2.3"
  },
  "engines": {
    "node": "^4.5 || 6.* || >= 7.*"
  },

When I look at the model, it looks like ember has rearranged its structure of how it stores data, and I'm wondering if the problem is related to how ember-source gives the data to ember-data, thats why it looks like an ember data problem.

Anything I can do to help debug?

[stephankaag]

I see this issue in my application as well. Something broke between 2.18 and 3.0.

In my case, I was able to trace it down to a computed-property that depends on the property that is not properly serialized. When I remove the computed-property the issue is solved.

[atomkirk]

Hmm, interesting. Whats the name of your property? I'm not seeing where I'm using notes in dependent keys, so I wonder if its truly related to computed properties.

[stephankaag]

The name of my property is amount and I have a dependent property [email protected] that appears to be related because I have no serializing troubles in ember-data >= 3.0 without it.

[akshaisarma]

I am seeing this too. I use offirgolan/ember-cp-validations which creates a bunch of computed properties on fields and I can confirm that turning it off for my problematic models fixes the issue.

[akshaisarma]

To elaborate, I did a bit of debugging to see what's happening and it looks like a stale computed property cache issue when the field is retrieved when a Snapshot object of it is created in Ember Data for serialization. Even though the model has the right values set in _attributes, the computed property finds a stale value in the cache for it. In my case, it only happens after the model is saved once.

[rwjblue]

Has anyone been able to put together a reproduction of this?

[atomkirk]

Sounds like all of our scenarios are quite different. The only common thread is that before 3.0, saving the model would send the attribute in the payload, and after 3.0, it doesn't. If 99.9% of apps are not seeing this problem, I expect this is a very tricky edge case and just as hard for you to debug as it would be for us to contrive an example that demonstrates it.

Help us help you, how have you guys handled debugging edge cases like this in the past? Are there some tips you can give to help us debug it ourselves and narrow down the cause within our own applications? Maybe that insight would reveal how we can create a demonstration app.

[atomkirk]

Well, in trying to create an example app I uncovered the "hacky" thing I'm doing that is probably the root of my bug. I verified the base case works in ember 3.1, so I'm going to close.

Basically, I must have a compound document saved altogether for validation, so I extended EmbeddedRecordsMixin to embed records in jsonapi. The problem arose from here:

createRecord('lineItem', {
  invoice: …,
  notes: '',
})

Then the template allows the user to edit notes. Which I showed gets set and is set right before save but then its back to '' in the payload. Funny thing is, if I remove notes: '', then it works. So something about setting an initial value here is causing empty data to use the initial value instead of the updated value when saving… If I don't set an initial value, save serializes the updated value. I'll close for now unless I can create an example app to demonstrate

[atomkirk]

Well why would this happen?

[atomkirk]

If I add this to my serializer, then it works:

  serialize(snapshot, options) {
    snapshot.record.lineItems.forEach(li => {
      li.eachAttribute(keyName => li._internalModel._record.set(keyName, Ember.get(li, keyName)));
    })
    return this._super(...arguments);
  },

Seems very specific to this model/serializer. I have other relationships with very similar structure and they work fine. I can't figure out what is different about them or that might help me create an example project.

So, whats happening is lineItem._internalModel._record is being created when I call createRecord('lineItem', but its not being updated when the line item property notes is edited. So, when its time to serialize, it uses the original value that was set on _record when I created the record. How is _record suppose to get updated and can you give me any guidance on how to debug why its not being updated?

[locks]

Thanks for originally reporting this! I'm closing due inactivity. If someone happens upon this problem with more recent versions, please file a new issue with a reproduction.