ember.js: Aborted transitions propagate error to Ember.RSVP.on('error',...)

We experienced this same issue with our error tracking platform Sentry and solved it with a workaround seen in this commit. Maybe it helps someone 😃

Edit: The Repository is no longer public.

I just merged a fix in ember-cli-sentry https://github.com/damiencaselli/ember-cli-sentry/pull/67

@Mifrill here you go:

import Ember from 'ember';
import RavenLogger from 'ember-cli-sentry/services/raven';

export default RavenLogger.extend({
  ignoreError(error) {
    // Ember 2.X seems to not catch `TransitionAborted` errors caused by
    // regular redirects. We don't want these errors to show up in Sentry
    // so we have to filter them ourselfs.
    //
    // Once this issue https://github.com/emberjs/ember.js/issues/12505 is
    // resolved we can remove this code.
    return error.name === 'TransitionAborted';
  },
});

There is a larger underlying issue here that goes beyond the commonly reported Sentry clutter. This seems to be also the root cause of https://github.com/ember-fastboot/ember-cli-fastboot/issues/202 as well which has a much greater impact as it can throw 500 errors or even crash fast boot server instances.

The inconsistent error handling and async handling causes a lot of differing behavior based on the types of promises and behavior of beforeModel and afterModel.

I went in and created a reproduction repository with the different pitfalls of how beforeModel will act differently based on various promise utilizations and implementations. https://github.com/rtablada/transition-aborted-example

In the example I take the basic docs redirect example and then do some fairly common changes to the method behavior or uses which drastically vary the behavior and response how TransitionAborted is surfaced.

For best replication, you’ll need to pull that repo and run it locally since I currently don’t have an instance of the fast boot server running publicly.

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @tchak @victor95pc is this still an issue, perhaps we should close, what do you think?

@pixelhandler it’s still an issue - I can reproduce it on Ember 3.8.3. I think we should consider removing inactive label, especially @robgarden provided repo for reproduction.

@ezpuzz Tiered authorization (not authentication) is an area we always run into this. We store the transition for later so that we can provide good UX, and ease developer pain when implementing routes. We don’t know which routes need elevated permission until they are hit, in which case we abort and ask for elevated credentials before a retry. A general sweeping statement that in many cases it’s bad UX is a misnomer.

Also to note, this error is raised in an async block, not offloaded to rsvp.on(‘error’

For browser errors this seems like it is more of an issue of noise. However, with Fastboot this becomes a bit more difficult, since the throw will stop everything. I haven’t been able to find a way to catch that particular error, and I suspect the issue is that the exception is being thrown inside of a promise error handler.

Out of curiosity, what is the value in that particular throw? I’m wondering if it could either be removed, or if the error handler could be moved so that it could be overridden.

I stoped using Ember, so I cant confirm it still a issue.

Thanks @stravid, this is exactly what I needed. Months of this bug and I finally found this thread and your workaround after much Google-fu. 🙇

Any update on this? I experience it in Ember 2.2.0 too.