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

@ofbriggs my best guess is that this commit - https://github.com/emberjs/ember.js/commit/94e1035a0eb66cc4d2a6624ff2557a331524f663 about 28 days ago addresses the behavior around TransitionAborted perhaps @chancancode or @rwjblue can answer this question.

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.

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

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

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);
    }
  });
}

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

+1

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 :)

+1

+1

+1

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

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 :)

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.

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

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

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

@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

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

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

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. :)

I do not have the chance to test it

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

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

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

Still seeing this in 3.8

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

+1 on 2.18.2

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.

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

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

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

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.

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

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

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