Issues with new save promise deprecation

[runspired]

The implementation in https://github.com/emberjs/data/pull/7868 has a few issues we should address.

• it does not allow for native object methods such as hasOwnProperty etc. that we would still expect to be present.
• it does not proxy properties correctly as it assumes return Reflect.get(...arguments) returns a method and calls .bind(target);. While we don't want to introduce a new behavior (dot notation lookups) we still do need to allow for the situation in which the property might be expected to be on the promise-object itself.

cc @machty @Turbo87 @snewcomer

[Turbo87]

for cross referencing: https://github.com/machty/ember-concurrency/issues/463

[runspired]

See #8025

[sly7-7]

@runspired I'm sorry, I can't see if this issue is supposed to be closed by #8025. I'm on 4.6.1 and still encounter something like https://github.com/machty/ember-concurrency/issues/463, so I guess some cases are not handled. I just don't know at all what should be done :(

[bartocc]

I was in the process of upgrading our codebase to [email protected]/4.6 this morning and, like @sly7-7 , could not figure if #8025 was supposed to fix everything or not…

[sly7-7]

🤔 @bartocc looking at the test in #8025, it seems expected to have a deprecation. Actually, this check returns false, but if ember-concurrency was using a "reel" symbol, I guess the deprecation would disappear ?

[Turbo87]

FWIW we're using https://github.com/mixonic/ember-cli-deprecation-workflow to simply disable the deprecation warning since it will silence itself again eventually

[runspired]

the original issues have been fixed but it now appears it can lead to infinite recursion of EC tasks in some scenarios: requires investigation.