Transition Rejection -> $transitions.onError triggered all the time

[adamlubek]

hey,
When running sample app I get Transition Rejection a lot and as a result $transitions.onError triggered all the time. Steps to reproduce:

1. npm install
2. open requiresAuth.hook.ts -> add "$transitions.onError({}, (transition) => {console.log('error');})" (see screenshot on bottom)
3. npm start
4. click any button (messages/contacts/preferences)
5. browser console:

• Transition #0-0: Started -> "Transition#0( ''{} -> 'welcome'{} )"
• trace.js:176 Transition #0-0: <- Success "Transition#0( ''{} -> 'welcome'{} )", final state: welcome
• trace.js:170 Transition No provider for UIView.PARENT_INJECT! #1-0: <- Rejected "Transition#1( 'welcome'{} -> 'mymessages'{} )", reason: Transition Rejection($id: 0 type: 2, message: The transition has been superseded by a different transition, detail: 'login'{})
• requiresAuth.hook.ts:30 error
• trace.js:133 Transition style(contacts): editContact.component: Fix comment inconsistent with code #2-0: Started -> "Transition#2( 'welcome'{} -> 'login'{} )"
• trace.js:176 Transition style(contacts): editContact.component: Fix comment inconsistent with code #2-0: <- Success "Transition#2( 'welcome'{} -> 'login'{} )", final state: login

Similar thing happens when refreshing page in the browser e.g.

1. npm start
2. click contacts
3. login as first available user
4. hit F5 or browser refresh button
5. again, Transition Rejection and $transitions.onError is triggered.

Generally, just clicking through the pages or refreshing the page surely shouldn't cause rejections and triggering error handling?

[adamlubek]

any update on this please? We would like to use UI-router for production code but issues like that are stopping us.

[christopherthielen]

hi @adamlubek sorry for the late (probably too late) response.

Every transition, once started, is either successful (meaning the destination state is active, etc) or it fails/errors. When a transition is redirected, the original transition is cancelled and a new one is started to the redirect target. Thus, the original transition has technically errorred. See this section of the Transition guide for more information.

If you want to filter specific types of errors, you can do so in your onError hook by checking the type of the TransitionRejection (see RejectType docs). For RejectType.SUPERSEDED, there is an additional redirected flag which tells you if the transition was superseded because of a redirect.

.onError({}, transition => {
  const err = transition.error();
  switch (err.type) {
    case RejectType.ERROR:
      // do error stuff
      break;
    case RejectType.SUPERSEDED:
    case RejectType.IGNORED:
      // ignore
      break;
  }
});

Sorry again, and hope this is helpful information