Ember.js: Safari browser: "You attempted to schedule an action in a queue (undefined) that doesn't exist"

Created on 5 Feb 2016 · 28Comments · Source: emberjs/ember.js

We are using Ember 1.11.3 and DS 1.0.0-beta.18.

In production we are seeing sporadic errors "You attempted to schedule an action in a queue (undefined) that doesn't exist" in our app on Safari 10.x (Mac OSX) and Mobile Safari 9 (iOS) browsers only.

It's not clear where these are originating--they seem to happen randomly and we cannot reproduce them. We are inserting into the run loop always via the standard API (Ember.run.schedule, etc.) and not through any custom hacks, so it's unclear how the queue could be undefined.

Any help/pointers to better understand the source of the error would be appreciated.

Source

johnnyshields

All 28 comments

FWIW, I also see these errors in our app which is on 1.11.4. We're close to upgrading to 2.2 so we haven't researched the issue too deeply

GavinJoyce on 5 Feb 2016

@GavinJoyce thanks for the note, please let me know if 2.2 yields positive results.

johnnyshields on 5 Feb 2016

Unfortunately 1.11.3 isn't really supported and without further information it doesn't really seem actionable.

I could suggest, add a conditional to the schedule function to detect the undefined bucket case and spewing the stack(by reporting to your bug tracking software or similar). Although minification may make the stack less then helpful, we may get lucky (especially if you have source maps for the result of the uglification).

It is also worth checking to see if your app or one of your addons is scheduling but somehow calculating the queue dynamically

stefanpenner on 5 Feb 2016

Closing this for now. Happy to help dig further if we can get more info as Stef suggested.

rwjblue on 5 Feb 2016

@stefanpenner

1.11.3 isn't really supported

1.11.0 was released less than a year ago, and 1.11.4 was released 21 days ago. Is there an LTS policy of Ember? It would help risk-averse users like me so we can stick to LTS versions only.

without further information it doesn't really seem actionable.

Despite lack of clues on the root cause, this is a legitimate issue. I see it around 50 times a day in my bug tracker randomly distributed across all my clients who use Safari. Since another user is seeing the same bug, I'd suggest to leave this open until at least we see how the 2.2 upgrade pans out.

add a conditional to the schedule function to detect the undefined bucket case and spewing the stack

I am doing so already, stack not showing anything meaningful and as you noted the minification makes matters worse. (Due to this 1 year old lingering issue I don't have source maps: https://github.com/ember-cli/ember-cli-uglify/issues/4)

johnnyshields on 5 Feb 2016

1.11.4 was released 21 days ago

This was a security patch only. We are not fixing non-security related bugs in 1.11.

Is there an LTS policy of Ember?

There is an LTS policy, but we have not released an official LTS version yet. The policy was created based on feedback received during the 2.0.0 process.

Despite lack of clues on the root cause, this is a legitimate issue.

No one has suggested that this is not a legit issue. We said that there is not much we can do. If you can provide a reproduction so that we can try to help figure out what is going on, we would gladly help. (as I mentioned in my comment above)

rwjblue on 5 Feb 2016

(Due to this 1 year old lingering issue I don't have source maps: ember-cli/ember-cli-uglify#4)

it appears like select2 is providing broken source maps, not sure how to solve that on our end?

stefanpenner on 5 Feb 2016

As the author noted in the issue it's not just select2, there are many libs which provide source maps which ember/uglify considers to be "bad" (I believe even Bootstrap had this issue.) Currently any single bad source map causes the overall compilation process to fail. Instead, Ember Uglify should ignore the bad source maps, spit out a warning, but still allow compilation.

johnnyshields on 5 Feb 2016

@johnnyshields awesome, I appreciate that you have a good understanding of the problem. Are you able to take your experience and provide us with a pull request to address this issue? It would be awesome, as I suspect it will help many with defunkt sourcemap inputs. (Unfortunately not something one of my own apps has encountered yet)

stefanpenner on 5 Feb 2016

Despite lack of clues on the root cause, this is a legitimate issue. I see it around 50 times a day in my bug tracker randomly distributed across all my clients who use Safari. Since another user is seeing the same bug, I'd suggest to leave this open until at least we see how the 2.2 upgrade pans out.

Ideas to debug this, see where schedule may be undefined.

in ember:

➜  ember.js ag -Q 'schedule('
packages/ember-application/lib/system/application.js
361:      run.schedule('actions', this, 'domReady', _instance);
660:      run.schedule('actions', this, 'domReady');

packages/ember-htmlbars/tests/attr_nodes/data_test.js
169:      run.schedule('render', function() {
175:      run.schedule('render', function() {

packages/ember-htmlbars/tests/helpers/view_test.js
310:    run.schedule('sync', function() {
316:    run.schedule('sync', function() {
351:    run.schedule('sync', function() {
357:    run.schedule('sync', function() {

packages/ember-metal/lib/binding.js
223:      run.schedule('sync', this, this._sync, obj);

packages/ember-metal/lib/run_loop.js
231:  run.schedule('sync', this, function() {
236:  run.schedule('actions', this, function() {

packages/ember-metal/lib/streams/stream_binding.js
38:      run.schedule('sync', this, this._sync);

packages/ember-metal/tests/run_loop/schedule_test.js
9:    run.schedule('actions', function() { cnt++; });
10:    run.schedule('actions', function() { cnt++; });
22:    run.schedule('actions', function() { cnt++; });
26:      run.schedule('actions', function() { cnt++; });
43:    run.schedule('sync', function() {
47:    run.schedule('actions', function() {
51:      run.schedule('actions', function() {
56:      run.schedule('sync', function() {
61:    run.schedule('destroy', function() {
72:    run.schedule('actions', function() {});
77:    run.schedule('actions', function() {});

packages/ember-metal/tests/run_loop/sync_test.js
14:        run.schedule('sync', syncfunc);
16:      run.schedule('actions', cntup);

packages/ember-metal/tests/run_loop/unwind_test.js
11:      run.schedule('actions', function() { throw new EmberError("boom!"); });

packages/ember-routing/lib/system/router.js
1054:  Ember.run.schedule('afterRender', function() {

packages/ember-runtime/lib/ext/rsvp.js
28:  run.backburner.schedule('actions', function() {

packages/ember-runtime/lib/system/core_object.js
383:    schedule('actions', this, this.willDestroy);
384:    schedule('destroy', this, this._scheduledDestroy);

packages/ember-views/lib/attr_nodes/attr_node.js
102:  run.schedule('render', this, this.renderIfDirty);

packages/ember-views/tests/system/ext_test.js
26:    run.schedule('afterRender', this, function() {

➜  ember.js ag -Q 'scheduleOnce('
packages/ember-extension-support/lib/data_adapter.js
289:        run.scheduleOnce('actions', this, onChange);

packages/ember-metal/lib/run_loop.js
361:    run.scheduleOnce('afterRender', myContext, sayHi);
362:    run.scheduleOnce('afterRender', myContext, sayHi);
373:    run.scheduleOnce('actions', myContext, function() {
429:      run.scheduleOnce('afterRender', this, 'processChildElements');

packages/ember-routing/lib/system/router.js
643:    this._slowTransitionTimer = run.scheduleOnce('routerTransitions', this, '_handleSlowTransition', transition, originRoute);

packages/ember-routing-views/lib/views/link.js
404:    run.scheduleOnce('routerTransitions', this, this._eagerUpdateUrl, transition, url);

packages/ember-views/lib/mixins/visibility_support.js
32:    run.scheduleOnce('render', this, this._toggleVisibility);

packages/ember-views/lib/system/renderer.js
23:    return run.scheduleOnce('render', ctx, fn);

packages/ember-views/lib/views/bound_if_view.js
13:      run.scheduleOnce('render', self, 'rerenderIfNeeded');

packages/ember-views/lib/views/bound_partial_view.js
20:      run.scheduleOnce('render', self, 'rerenderIfNeeded');

packages/ember-views/lib/views/container_view.js
391:    run.scheduleOnce('render', view, '_ensureChildrenAreInDOM');

packages/ember-views/lib/views/simple_bound_view.js
73:        this.updateId = run.scheduleOnce('render', this, 'update');
104:    run.scheduleOnce('render', view, 'rerender');

packages/ember-views/lib/views/states/has_element.js
37:    run.scheduleOnce('render', function () {

packages/ember-views/lib/views/with_view.js
19:      run.scheduleOnce('render', self, 'rerenderIfNeeded');

packages/ember-views/lib/views/view.js
1344:      run.scheduleOnce('render', this, stateCheckedFn);

➜  data git co v1.0.0-beta.18
HEAD is now at c2871da... release v1.0.0-beta.18
➜  data ag -Q 'schedule('
packages/ember-data/lib/adapters/fixture-adapter.js
338:        Ember.run.schedule('actions', null, function() {

packages/ember-data/lib/system/model/model.js
956:    Ember.run.schedule('actions', this, this.updateRecordArrays);
1194:    Ember.run.schedule('actions', this, '_triggerDeferredTriggers');

packages/ember-data/lib/system/record-array-manager.js
37:    Ember.run.schedule('actions', this, this.updateRecordArrays);

packages/ember-data/lib/system/relationships/state/relationship.js
202:      self.store._backburner.schedule('syncRelationships', self, self.flushCanonical);

packages/ember-data/lib/system/store.js
1309:      this._backburner.schedule('normalizeRelationships', this, '_setupRelationships', record, record.constructor, data);
1597:      store._backburner.schedule('normalizeRelationships', store, '_setupRelationships', record, type, data);

➜  data ag -Q 'scheduleOnce('
packages/ember-data/lib/system/store.js
687:    Ember.run.scheduleOnce('afterRender', this, this.flushAllPendingFetches);

In BB (at the sha your version uses):

➜  backburner.js git:(master) git co f4bd6a2df221240ed36d140f0c53c036a7ecacad
HEAD is now at f4bd6a2... Merge pull request #119 from mmun/join
➜  backburner.js ag -Q 'schedule('
lib/backburner.js
163:    return this.currentInstance.schedule(queueName, target, method, args, false, stack);
192:    return this.currentInstance.schedule(queueName, target, method, args, true, stack);
504:      backburner.schedule(backburner.options.defaultQueue, null, fns[i]);

tests/autorun_test.js
12:  bb.schedule('zomg', null, function() {

tests/bb_has_timers_test.js
12:  bb.schedule('ohai', null, function () {

tests/join_test.js
87:    bb.schedule('one', function() {
92:      bb.schedule('one', function() {
97:    bb.schedule('one', function() {

tests/queue_test.js
14:    bb.schedule('two', null, function() {
17:      bb.schedule('one', null, function() {
22:    bb.schedule('two', null, function() {
39:        bb.schedule('one', increment);
44:        bb.schedule('one', increment);

This does reveal one place, where this issue may be happening (the only place where dynamic input is provided) here

Now it would be great to know if this is the source of the issue, it may be. Or it may be user code/addon code that schedules something with a dynamic queue name.

I think you should be able to annotate your source, to attach a bit more information if the linked code-path is the source of the issue. This would help us confirm it is an issue in ember. An maybe some hints as to whats up.

Also, providing your stack (although post uglification sans-sourcemap) may yield a further hint.

stefanpenner on 5 Feb 2016

@stefanpenner thank you, that looks like a plausible lead. I appreciate your time to take a look at this.

About ember uglify I will take a look.

johnnyshields on 5 Feb 2016

About ember uglify I will take a look.

you solution seems legit. if the SM looks bad log a warning, then insert an alternative map set and drop it, the SM concat should already detect this and add the appropriate padding.

stefanpenner on 5 Feb 2016

@stefanpenner thank you, that looks like a plausible lead. I appreciate your time to take a look at this.

Share if you find more related info. It seems seems very strange that the defautlQueue would be undefined.

stefanpenner on 5 Feb 2016

We were finally able to reproduce the issue on iOS (which still occurred very randomly) and we believe it was fixed inadvertently by this PR:

emberjs/ember.js#10634

We expect that upgrading from 1.11.4 to 1.12.2 should fix the issue.

johnnyshields on 1 Mar 2016

Just some more info, the root cause seems to be a JIT compilation bug in Safari--essentially it wasn't evaluating arguments. The change in emberjs/ember.js#10634 inadvertently fixed it. The aggravating thing about this bug is that if you open the Safari debugger, the JIT compilation changes so that the bug doesn't occur!

johnnyshields on 1 Mar 2016

👍1

Just some more info, the root cause seems to be a JIT compilation bug in Safari

Ug, these blow to debug. Is it possible to reproduce, as it is likely worth reporting here

stefanpenner on 1 Mar 2016

~~hmm, actually reading the source I wonder if I inadvertently fixed something here~~

nm, it was just purely named args vs argz before.

stefanpenner on 1 Mar 2016

my guess is one of the following to be responsible:

https://github.com/emberjs/ember.js/pull/10634/files#diff-33ff1529a427727ffe2425f145375540L255
https://github.com/emberjs/ember.js/pull/10634/files#diff-33ff1529a427727ffe2425f145375540L395

or maybe...

https://github.com/emberjs/ember.js/pull/10634/files#diff-33ff1529a427727ffe2425f145375540L333

If you have some cycles, trying to patch one at a time may help us narrow it down.

stefanpenner on 1 Mar 2016

@stefanpenner I agree the change from .apply(this, arguments) to (...arguments) made the difference in how Safari JIT handles it. At this point it's not worth to find which exact line; I know as much as I care to know about this issue :neutral_face: and for anyone looking to fix it, the answer is to upgrade to Ember 1.12

johnnyshields on 1 Mar 2016

@johnnyshields is it by any chance specific to certain safari devices or just any architecture?

stefanpenner on 1 Mar 2016

I see the following stats:

Browser

80% Mobile safari (9.0 and 9.2)
14% Safari (9.0 and 9.2)
6% Chrome mobile iOS (v48.0.2564)

82% iOS 9.2
8% Mac OSX 10.9
10% other

(Our user base is much more heavy iOS than Mac OSX so probably on a given Apple device it occurs with roughly the same frequency)

johnnyshields on 1 Mar 2016

thats the breakdown of exceptions per runtime?

stefanpenner on 1 Mar 2016

For this specific exception, this is the breakdown of the source which reported it. So if it happened 100 times, 80 of out 100 reports were from Mobile Safari.

johnnyshields on 1 Mar 2016

Ignoring the % numbers, the key point is that I do NOT seeing it happen on PC or Android browsers, it's only Safari and iOS Chrome.

johnnyshields on 1 Mar 2016

@johanneswuerbach ya, it seems totally a Webkit/JSC thing (iOS chrome just uses JSC / webkit under the hood, on iOS they largely just provided different UI + networking)

stefanpenner on 1 Mar 2016

could this be related? https://bugs.webkit.org/show_bug.cgi?id=156034

stefanpenner on 31 Mar 2016

Seeing this error on Microsoft Edge 13.10586 on Windows 10 from one of our users. Cannot reproduce it myself though.