Errors regarding nested transactions #484
Comments
|
My app is also doing this only in production mode but at the moment i'm only observing it in IE11 users.
User agent string: Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko I have my app report JS errors in production to me and one single user is generating 200+ errors per minute. |
|
I've also only observed it in production, but also on macs: It seems to always occur after an error like this: That occurs when something is trying to |
|
Actually now i'm seeing more users throwing the error in various browsers. I'm going to have to roll back until this gets sorted. (130k errors and counting...) I still can't reproduce the error but the explanation from @kbullaughey does seem plausible as all my errors are occurring within a page that holds a google map that i have integrated into ember and google maps likes to move DOM nodes around. (As far as i know i got that all sorted with the initial glimmer 2.0 release though..) |
|
Also here are some sample stack dumps. |
|
I'm seeing similar errors, but reproducible locally as well. Here's my stacktrace: |
|
I get that in the most current chrome. |
|
I'm seeing quite a few of these as well. From our error tracking, it looks like this is triggered when something rendering throws an exception. The app then becomes completely unusable without a page refresh :/ |
|
When I have ran into this, it has been a red herring of sorts. Basically some other error occurs during render, putting the VM into a bad state, which results in this error. So although glimmer also needs to address being able to recover correctly, you may want to look for other errors in the console and address them. (my example was someone trying to use nodeList.forEach on IE edge, yours is likely different) |
|
My guess is if throws, then never resets the transition, and all subsequent renders will fail. |
|
hypothetical fix: #505 (i need to actually write tests and confirm, so don't get too exited yet) |
* ensure running `commit` always clears the current transaction * if we begin a transaction with an existing transaction warn, commit it, then start begin the next.
|
Any errors thrown during rendering will leave the transactions in a bad state, and therefore you would have these I suspect that the reason these issues are cropping up more often recently is due to a bug that existed in Ember 2.13.0. In Ember 2.13.0 any Can those of you affected ensure you are updated to Ember 2.13.2, monitor these errors and report back? |
|
I guess in my case, this is the error: which causes the nested transaction Error Versions: Dependencies: |
|
@rwjblue I tried using Ember 2.13.2 as you suggested but am still see the following errors with our app. In my case I only see these errors when using |
|
For me to have rendering continue without the need to reload the browser like proposed above would be a dream and enough. It's pretty clear that we didn't see this anymore after fixing remaining addon upgrade errors. So basically any error triggers this imho. We can keep our code always working of course 😬 But there's always the one thing that slips through the net. This is where glimmer can shine and show some resilience. |
* ensure running `commit` always clears the current transaction * if we begin a transaction with an existing transaction warn, commit it, then start begin the next.
* ensure running `commit` always clears the current transaction * if we begin a transaction with an existing transaction warn, commit it, then start begin the next.
* ensure running `commit` always clears the current transaction * if we begin a transaction with an existing transaction warn, commit it, then start begin the next.
ya ^^ is the reason, we will release a new ember without this assertion. |
[BUGFIX #484] ensure transactions are always.
|
Well i started getting them again after the 2.15.0 upgrade from 2.14.0. This time it appears mostly on IE11 machines. I'm at 900 errors and counting as people start using the new version. Not looking good. EDIT: |
|
This is happening in the following browser: |
|
Same error for me
"devDependencies": {
"ember-cli": "~2.15.0-beta.2",
"ember-source": "~2.15.0-beta.2"
} |
|
Getting the same error in 2.15, after downgrading to 2.14 the error went away |
|
Same issue here in 2.16.0 |
|
got this error in IE11 and also on v2.16.0 |
|
Getting the error
with 2.16.2. This happening with IE 11 as well as a few different versions of Chrome, 58.0.3029.110 and 62.0.3202.94 (latest). I'm only seeing this in our airbrake logs and haven't even been able to reproduce it, which is extra frustrating. It does seem to happen in batches of about 8-12 errors for one session over the course of ~1 minute. |
|
Seeing the same error |
|
Seeing the same error here:
|
|
We're seeing a lot of these in our logs, and like mentioned above they tend to happen in batches for a single browser session. However, we have not been seeing other errors for those sessions. Also, while I have seen this error throw when something else fails (especially in dev), it doesn't tend to throw repeatedly like we are seeing in our logs. Is it possible this is just noise? Given the frequency of the errors, I would have expected to hear back from our customers, but we haven't received any feedback about the page failing to render. (But maybe we just have really patient customers!) |
|
Also getting this issue:
Using Chrome 63.0.3239.84 |
|
Even getting this error in |
|
Just reporting that issue has appeared again. Even in local builds. Error occurs when trying to perform any transaction immediately after any other error occurs, i.e Prev transaction didn't complete due to js error. ember -v Pkg versions Error: |
|
We're seeing this issue in 2.18 as well. Is there any update on this issue? We want to get our app up to the latest LTS candidate. |
|
A concrete reproduction would be very helpful here... |
|
I created jsbin here . I tried using same jsbin with older ember releases and seems it started from ember 2.15.0. Any help would be appreciated. |
|
Ember 2.15 updated versions of glimmer-vm, which is why things changed in that version. FWIW, we are getting ready to update glimmer-vm to latest again on Ember master branch (targeting 3.1)... |
|
@rwjblue here's one reproduction of the issue: https://ember-twiddle.com/784e904b6ec59dbcb454b1c17ed237d8?openFiles=templates.application.hbs%2C
|
|
A more general reproduction: export default Component.extend({
init() {
this._super(...arguments);
throw 'a little exception';
}
});https://ember-twiddle.com/d64ffa7e42703cc42f1ff829eeb0328c?openFiles=templates.application.hbs%2C This has the side effect of producing two runtime exceptions:
|
|
@GavinJoyce - Thank you for the simple reproduction! I have submitted emberjs/ember.js#16174 with (previously failing) tests for the specific scenario you provide and the fix. |
|
@GavinJoyce - Also, FWIW, I think that second error you were seeing:
Is actually from the ember-inspector here, and would only happen if you had it open. Definitely still something to fix, but its a different beast... |
|
There may still be more scenarios that will trigger this issue, if there are lets open a new issue with a specific reproduction. Given a reproduction (like @GavinJoyce did in #484 (comment)) it should be straightforward to address the various scenarios that come up... |
|
getting this error in 3.0.0-beta.1 when I navigate between sibling routes |
|
In all known cases of this message, an error from user land code is thrown before the “nested transaction” error. As mentioned in the prior comment, please report a new issue with a reproduction. At this point (with Ember 3.0) we really need to know where the user land errors are still being thrown that isn’t already handled properly by the recovery mechanisms in place... |
|
ill try to find out, I didnt see any other errors in console other than a string of this same error |
and others
I've started to observe hard-to-reproduce errors of the form:
Which seem to come from an assert statement introduced in PR #444 in file:
I've only noticed this on my production Ember app which is hard to debug given the call stack of the error just goes up backburner/runloop chain and never touches my own code.
The errors often occur a handful at a time.
Anyone have thoughts on where to dig to either reproduce or resolve such errors?
The text was updated successfully, but these errors were encountered: