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

[olivia]

As seen in this example, aborted transitions (through redirection or manual abortion) propagates a TransitionAborted error to the RSVP error handler while in 1.x it does not. Was this an intentional change or is the error an erroneous error?

[pixelhandler]

@OFbriggs my best guess is that this commit - 94e1035 about 28 days ago addresses the behavior around TransitionAborted perhaps @chancancode or @rwjblue can answer this question.

[chancancode]

I doubt that my commit changed that particular behavior, but I personally agree that it seems better not to propagate this to RSVP, although I am not sure what exactly has changed.

I might be looking into something related next week (routes instrumentation), so if no one else have figured it out by then I might uncover why as part of that work.

[stefanpenner]

It seems like some internals are not handling the rejection, this should be considered a bug.

If the rejection is handled in the same turn, it does not propagate to on('error

[bkCDL]

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

[jbryson3]

For now I'm just hardcoding the name of the error as a workaround.

export default function onServerError(cb) {
  Ember.RSVP.on('error', (reason) => {
    // An aborted transition propogates an error to RSVP
    if(reason.name !== 'TransitionAborted') {
      cb(reason);
    }
  });
}

[stianpr]

Any progress on this? We're experiencing this on Ember 2.3 as well.

[remkoboschker]

+1

[stravid]

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.

[gertjanwytynck]

+1

[bugduino]

+1

[jemware]

+1

[devinus]

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. 🙇

[stravid]

Thanks for the kind words @devinus, I will try to write a little blog post so in the future not so much Google-fu is needed :)

[victor95pc]

Thanks @stravid, but it still not a solution, maybe we can add more args on the error callback to check if the model's request fail.

[tchak]

I just merged a fix in ember-cli-sentry ember-cli-sentry/ember-cli-sentry#67

[bichotll]

Experienced it in Ember 2.5 (we are in the process to update Ember version).
For future reference, I recommend the use of ember-cli-sentry ^.

Before we found the origin of the error we even had to upgrade our sentry subscription due the amount of false alarms...plus one afternoon/evening...

[cbou]

I also lose some time to figure out this was a false positive error.

using transitionTo inside redirect is documented in the guide and in the API:
https://emberjs.com/api/ember/2.18/classes/Route/methods/redirect?anchor=redirect

Nevertheless it still produces an error:
https://ember-twiddle.com/41c21d19e962b4981c967e46228452bb

It would save the time of a lot of emberjs new comers

[dtropp]

@chancancode or @rwjblue Planning any changes to this behaviour?
We are seeing this when we have a guard in a beforeModel() that transitions to a different route.
We are still seeing it on Ember 2.16

[pixelhandler]

@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?

[bichotll]

I barely use Ember nowadays, but I suppose you could try to reproduce it by forking this and updating the Ember version?
http://emberjs.jsbin.com/wiruqobiqe/1/edit?output

[Boubalou]

Same as @bichotll, I ended up doing backend works lately and not much into Ember anymore. I will let you guys decide whatever is good for this. :)

[bugduino]

I do not have the chance to test it

[victor95pc]

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

[mpirio]

It seems it still an issue : https://ember-twiddle.com/fe0e87339fd079e212d5713f5288ce58

[fpauser]

Yes, it is still an issue (tested with ember-3.5.0).

[saleswhale-vincent]

Still seeing this in 3.8

[robgarden]

Reproduction on 3.10.0: https://github.com/robgarden/ember-transition-aborted-reproduction

[markyky]

+1 on 2.18.2

[thec0keman]

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.

[lucasm-iRonin]

@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.

[Exelord]

I agree. It's very annoying issue. Its also blocking tests if you are testing if the transition has been aborted

[James1x0]

Our catch statements for transitions that may hit an abort explicitly check for this error. Still a pain though...

[ezpuzz]

Question to answer is if we ever care about TransitionAbortedError, can it happen in a way that we want the exception reported? It can be useful to know when user is getting redirected (this is usually unexpected behavior for user or bad UX, user should know where they are going when they click on something).

In many cases you should consider where the user is going before you get to redirecting them and use redirects as a last resort. Those "spurious" errors being reported are actually indications of bad UX design I think.

Of course I am affected by this issue because in many cases you don't know how to direct the user until after the model hook has fired... such as a field having changed on the backend. Still good to give user feedback about the transition instead of redirecting them silently.

That's why I think it's a good thing that they are thrown, it gives the opportunity to alert the user to an unexpected transition and remind you of places where your user experience can be improved.

[James1x0]

@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’

[ezpuzz]

Also if you don't override RSVP.on('error') this code runs which swallows the error: https://github.com/emberjs/ember.js/blob/master/packages/@ember/-internals/runtime/lib/ext/rsvp.js

[ezpuzz]

@James1x0 sorry, what I meant is that there are useful cases of throwing the exception (one being identifying user pain points) but the current error doesn't include enough information right now to make it a useful bug report. In your use case you might want to record from what attempted transition the user was prompted for elevated credentials and that may happen at many possible places in your app.

In that case we could improve the usefulness of the error here: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition-aborted-error.ts

by passing more about the transition here: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition.ts#L401

It could be ignored otherwise as mentioned in my last comment.

[Mifrill]

Hi, @stravid about your message:
#12505 (comment)
The link "workaround seen in this commit." is broken:

can you update it, please?

[stravid]

@Mifrill sorry that is not possible, I made the repository private.

[Mifrill]

@stravid okay, no problem, can you please then post a short snippet with an example which not contains any private info

[stravid]

@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';
  },
});

[runspired]

still an issue in 4.x

[rtablada]

There is a larger underlying issue here that goes beyond the commonly reported Sentry clutter. This seems to be also the root cause of ember-fastboot/ember-cli-fastboot#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.