Failing test: manually-reverted values are too "sticky"

[mwpastore]

Consider a template with a form to manipulate a property of a changeset. If you use template actions to change the property away from and subsequently back to its pristine value, it can't be changed again using a template action.

[mwpastore]

I traced it all the way through to where validated-changeset calls Ember.set on the changes object (from here to here). The first time around, when you use a template action to set aProperty to bar, it calls:

options.safeSet(
  {}, // target
  "aProperty", // path
  { value: "bar" } // value
)

After this operation, target (changes) looks like: aProperty: { value: "bar" }.

The second time around, after setting aProperty to foo and then to qux, it calls:

options.safeSet(
  {}, // target
  "aProperty", // path
  { value: "qux" } // value
)

After this operation, target (changes) looks like: {}.

So for whatever reason Ember.set is buffering or otherwise swallowing this operation.

[mwpastore]

Welp, there's either too much property notification happening or not enough. 😂 If I modify setDeep to just do target[path] = value instead of calling safeSet, this test passes. But it breaks other things (as one might expect). Not sure where to go from here... feeling a bit out over my skis!

[snewcomer]

@mwpastore I'm digging into Ember.set and it looks like it is only a problem in DEBUG mode (some WeakMap logistics with Ember.set in dev/test mode). Will keep digging and paste when/if I get a valid test case!

[snewcomer]

Fixed by emberjs/ember.js#18961

Looks like this was fixed 2 months ago here ☝️!!! This looks like 3.20-beta series. Checking if it is something can be backported but I'm guessing not.

[mwpastore]

Sure enough, my test passes on ember-beta! Thanks @snewcomer!