Ember.js: Bug with computed property not recomputed when gotten

[boris-petrov]

Here is a reproduction repo.

Run the server and press the button - in the console it will say bg-BG en BG which is wrong - it should be bg-BG bg BG. Let me explain a bit the code.

There is an empty configuration service and an i18n service that has a few computed properties that depend on configuration.locale. The button just does a this.set('configuration.locale', 'bg-BG');. There is an observer on i18n.locale which has the console.log in it. It uses all computed properties in the i18n service (all of which depend on the changed configuration.locale) but they are not recomputed correctly when gotten.

A couple of notes - I've explicitly put {{this.i18n.language}} in the template. Removing it fixes the issue, no idea why. Also putting the console.log inside a next call "fixes" the problem.

I believe this is a bug. In the console.log getting i18n.language should recompute the property because it depends on configuration.locale which was just changed.

[krisselden]

Was this something that was working then stopped working? If so, do you know the last good version?

[boris-petrov]

It's something I recently discovered so I don't know if it did work before. I would think that this was always broken. But it's an easy check (just changing the version in package.json) if that would help the debugging.

[pzuraq]

We dug into this last week, the core issue is that the chained observers are firing _before_ the notifications have finished doing invalidations. This is another problem of bug related to eager observers, and the fact that they fire immediately.

We're currently discussing/planning some refactors to observers that would change their timing semantics so that they would run only once per runloop, and would definitely run _after_ all CPs were invalidated. This would also allow us to drop chains for observers, so it really would be wins all around. I'm hoping we can push forward on that work to solve this issue.

[boris-petrov]

@pzuraq - thank you for the detailed answer. Which release will you be targeting if you start fixing this - 3.11 perhaps? Also, please check #17393 - it also includes observers - so be sure to not miss that case when you're discussing some refactoring/change of semantics. @bekzod even wrote a failing test for that other issue.

[pzuraq]

Sorry I haven't been able to get back to you on this! So, the new stuff has landed behind the EMBER_METAL_TRACKED_PROPERTIES feature flag, we're not sure which version that'll land in just yet because there are some performance issues we're working on, but you can preview it there! Let us know if the problem persists even with that on

[boris-petrov]

@pzuraq - no worries. I don't think I'll be able to test canary with feature flags (at least not soon) but take your time, no problem. Let's just leave these few issues open here so we/you don't forget them. Thanks for the support!

[boris-petrov]

@pzuraq - I tested this project on 3.13 and the problem seems fixed. Is that so? Can we close this issue?

[pzuraq]

Awesome, thanks for following up 😄 to clarify, you can now opt-in to observers being async by default, which should prevent this from occurring in general. There were also lots of small changes to the exact timing semantics of observers and CPs, so its possible the fix worked for sync observers as well.