Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting "Uncaught Error: infinite rendering invalidation detected" with 2.9-beta3 #14351

Closed
jrjohnson opened this issue Sep 25, 2016 · 19 comments · Fixed by #14520
Closed

Getting "Uncaught Error: infinite rendering invalidation detected" with 2.9-beta3 #14351

jrjohnson opened this issue Sep 25, 2016 · 19 comments · Fixed by #14520

Comments

@jrjohnson
Copy link
Sponsor

In attempting to test compatibility with ember-beta I'm seeing an issue. With 2.9-beta2 I was getting a white screen with no ember container and no content rendered. With beta3 I'm getting a flash of the content followed by a white screen, but now I'm seeing the error "infinite rendering invalidation detected" in the console.

Code (with updated ember) is here:
https://github.com/ilios/frontend/tree/ember-beta-test

Demo which shows error can be seen here:
https://ember-beta-test--ilios-frontend.netlify.com

It does not show up on the login page, only post-authentication so you have to login. You can do so with:
username: demo_faculty1
password: demofaculty1

The error seems to be present on every route.

I also tried a build with #master but it has the same error. I'm not sure how to track down where the issues is occurring because the stack trace is just full of ember-debug lines, but I'm happy to provide any info or help. I think my next step is to start pulling out individual addons to see if I can find a culprit unless someone else has seen this error or knows about it already. It seems strange that the /login is not affected, but every other route is.

@fivetanley
Copy link
Member

fivetanley commented Sep 28, 2016

this seems to happen with class based helpers (e.g. Ember.Helper.extend based helpers), our pages (Heroku dashboard, not the app listed above) using https://github.com/fivetanley/ember-promise-helpers experience this error also. I'll see if I can dig in a bit more.

@fivetanley
Copy link
Member

I can reproduce locally on ember-promise-helpers with ember try ember-beta test --server

@snewcomer
Copy link
Contributor

This is something I am encountering quite often in my test suite. Seems related to run wrapping an expression. When removed, error goes away.

@adam-knights
Copy link

@fivetanley I originally opened #14456, but I think it may be a dupe of this (although I see this in Ember 2.8, not just 2.9)

This is the twiddle: https://ember-twiddle.com/18b75f7761ba740567c1829660ce28e1?openFiles=templates.application.hbs%2C

To reproduce simply goto the application.hbs, and add the final {{/if}} (warning this will cause your browser and computer to cry)

@chancancode chancancode modified the milestone: 2.10.0 Oct 17, 2016
@jrjohnson
Copy link
Sponsor Author

I'm no longer seeing this error in my application with the release of 2.9.0. I'm inclined to close this as having been resolved elsewhere. @fivetanley or @snewcomer - are you still seeing this issue in 2.9.0?

@fivetanley
Copy link
Member

@jrjohnson That's because 2.9.0 is basically 2.8.3. It does not use the new glimmer 2 rendering engine. @chancancode and I tracked this one down and I owe him some failing tests 😄

@jrjohnson
Copy link
Sponsor Author

Ah! I didn't know that. I thought 2.9.0 included glimmer2 - I obviously missed that critical announcement. I will leave this open then. Thanks.

tilde-engineering pushed a commit to tildeio/ember.js that referenced this issue Oct 26, 2016
This pulls in two glimmer-engine bugfixes:

- local variables (block params) should always win over helpers
- stateful/class-based helpers used in `{{#if (my-helper ...)}}` and
  other block arguments position are destroyed when the block syntax
  switches from default to inverse (and vice versa)

Fixes emberjs#14351, emberjs#14413
tilde-engineering pushed a commit to tildeio/ember.js that referenced this issue Oct 26, 2016
This pulls in two glimmer-engine bugfixes:

- local variables (block params) should always win over helpers
- stateful/class-based helpers used in `{{#if (my-helper ...)}}` and
  other block arguments position are destroyed when the block syntax
  switches from default to inverse (and vice versa)

Fixes emberjs#14351, emberjs#14413
chancancode added a commit that referenced this issue Oct 26, 2016
This pulls in two glimmer-engine bugfixes:

- local variables (block params) should always win over helpers
- stateful/class-based helpers used in `{{#if (my-helper ...)}}` and
  other block arguments position are destroyed when the block syntax
  switches from default to inverse (and vice versa)

Fixes #14351, #14413

(cherry picked from commit 8c87e50)
@chancancode
Copy link
Member

I believe this is fixed in #14520. I verified that it at least fixed @adam-knights' gist. @fivetanley @jrjohnson can you confirm? (The fix is available in ember#beta or ember#2.10.0-beta.2 – I am in the middle of releasing the latter, but it'll probably be up by the time you see this.)

@chancancode
Copy link
Member

The actual fix (and tests) are in glimmerjs/glimmer-vm#337

@jrjohnson
Copy link
Sponsor Author

@chancancode quick click around in my app and this appears to be fixed in ember#2.10.0-beta.2. Thanks!

@Turbo87
Copy link
Member

Turbo87 commented Nov 11, 2016

@chancancode I'm running 2.10.0-beta.3 at the moment and some of my users still seem to be hitting this error. Can't reproduce locally unfortunately.

@acburdine
Copy link

I am getting this error now when testing Ghost-Admin on 2.10.0-beta.3. Tried going to 2.10.0-beta.2 as well, with the same result.

@Turbo87
Copy link
Member

Turbo87 commented Nov 23, 2016

@acburdine are you able to reproduce this consistently? could you write down some instruction on how to reproduce it?

@acburdine
Copy link

yup - happens every time I render the page.

Repro steps:

  • get Ghost itself set up
  • update Ghost-Admin to 2.10.0-beta.3
  • visit index page when you have >= 1 post

Currently I'm drilling down as to the cause of this. I think I've got it narrowed down to a specific component that's doing a {{yield this}} in its template

@acburdine
Copy link

acburdine commented Nov 23, 2016

@Turbo87 I think I figured it out - the component I mentioned above was using some old code borrowed from ember-cli-active-link-wrapper and I'm assuming that's what broke it. Updating to use the actual ember-cli-active-link-wrapper addon fixed the issue

@Turbo87
Copy link
Member

Turbo87 commented Nov 23, 2016

hmm, I'm using ember-cli-active-link-wrapper in my app too. Some of my users are still hitting that error, but I haven't been able to reproduce it. It's possible that this addon is still doing some funky stuff...

@RobbieTheWagner
Copy link
Member

Does anyone know some specific lines of code that are causing this issue? We have this error in a bunch of our tests, and I am not sure what is causing it.

@srvance
Copy link
Contributor

srvance commented Mar 14, 2017

Similar issues in the above ember-bootstrap issue in the code that manages the same kind of behavior as ember-cli-active-link-wrapper. If you take the two code snippets provided by users in the issue and paste them into your application.hbs you can reproduce. The e-b code around it is a little intricate, though.

@knownasilya
Copy link
Contributor

knownasilya commented Apr 27, 2017

Also seeing this error after I updated to the latest cli version using ember-source. Seeing it in my app. Ember 2.12.2

For me it was machty/ember-concurrency#134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants