Ember.js: Las transiciones abortadas propagan el error a Ember.RSVP.on ('error', ...)

@ofbriggs, mi mejor suposición es que este compromiso: https://github.com/emberjs/ember.js/commit/94e1035a0eb66cc4d2a6624ff2557a331524f663 hace aproximadamente 28 días aborda el comportamiento en torno a TransitionAborted quizás @chancancode o @rwjblue pueden responder a esto pregunta.

Dudo que mi compromiso haya cambiado ese comportamiento en particular, pero personalmente estoy de acuerdo en que parece mejor no propagar esto a RSVP, aunque no estoy seguro de qué ha cambiado exactamente.

Es posible que esté investigando algo relacionado la próxima semana (instrumentación de rutas), por lo que si nadie más lo ha descubierto para entonces, podría descubrir por qué como parte de ese trabajo.

Parece que algunos internos no están manejando el rechazo, esto debería considerarse un error.

Si el rechazo se maneja en el mismo turno, no se propaga a on('error

¿Algún avance en esto? También lo experimento en Ember 2.2.0.

Por ahora, solo estoy codificando el nombre del error como solución.

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

¿Algún progreso en esto? También estamos experimentando esto en Ember 2.3.

+1

Experimentamos este mismo problema con nuestra plataforma de seguimiento de errores Sentry y lo resolvimos con una solución alternativa que se ve en esta confirmación . Tal vez ayude a alguien :)

+1

+1

+1

Gracias @stravid , esto es exactamente lo que necesitaba. Meses de este error y finalmente encontré este hilo y su solución después de mucho Google-fu. 🙇

Gracias por las amables palabras @devinus , intentaré escribir una pequeña publicación en el blog para que en el futuro no se necesite tanto Google-fu :)

Gracias @stravid , pero aún no es una solución, tal vez podamos agregar más argumentos en la devolución de llamada de error para verificar si la solicitud del modelo falla.

Acabo de fusionar una solución en ember-cli-sentry https://github.com/damiencaselli/ember-cli-sentry/pull/67

Lo experimenté en Ember 2.5 (estamos en el proceso de actualizar la versión de Ember).
Para referencia futura, recomiendo el uso de ember-cli-sentry ^.

Antes de encontrar el origen del error, incluso tuvimos que actualizar nuestra suscripción de centinela debido a la cantidad de falsas alarmas ... más una tarde / noche ...

También pierdo algo de tiempo para darme cuenta de que se trata de un error falso positivo.

el uso de transitionTo dentro de redirect está documentado en la guía y en la API:
https://emberjs.com/api/ember/2.18/classes/Route/methods/redirect?anchor=redirect

Sin embargo, todavía produce un error:
https://ember-twiddle.com/41c21d19e962b4981c967e46228452bb

Ahorraría el tiempo de muchos recién llegados de emberjs

@chancancode o @rwjblue ¿ Está planeando algún cambio en este comportamiento?
Estamos viendo esto cuando tenemos un guardia en un beforeModel() que cambia a una ruta diferente.
Todavía lo estamos viendo en Ember 2.16

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @tchak @ victor todavía deberíamos cerrar un problema de

Apenas uso Ember hoy en día, pero supongo que podrías intentar reproducirlo bifurcando esto y actualizando la versión de Ember.
http://emberjs.jsbin.com/wiruqobiqe/1/edit?output

Al igual que @bichotll , terminé haciendo trabajos de backend últimamente y ya no me

No tengo la oportunidad de probarlo

Dejé de usar Ember, así que no puedo confirmar que sigue siendo un problema.

Parece que sigue siendo un problema: https://ember-twiddle.com/fe0e87339fd079e212d5713f5288ce58

Sí, sigue siendo un problema (probado con ember-3.5.0).

Sigo viendo esto en 3.8

Reproducción en 3.10.0: https://github.com/robgarden/ember-transition-aborted-reproduction

+1 en 2.18.2

En el caso de errores del navegador, parece que se trata más bien de un problema de ruido. Sin embargo, con Fastboot esto se vuelve un poco más difícil, ya que el lanzamiento detendrá todo. No he podido encontrar una manera de detectar ese error en particular, y sospecho que el problema es que la excepción se lanza dentro de un controlador de errores de promesa.

Por curiosidad, ¿cuál es el valor de ese lanzamiento en particular? Me pregunto si podría eliminarse o si el controlador de errores podría moverse para que se pueda anular.

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @tchak @ victor todavía deberíamos cerrar un problema de

@pixelhandler sigue siendo un problema, puedo reproducirlo en Ember 3.8.3. Creo que deberíamos considerar eliminar la etiqueta inactive , especialmente @robgarden proporcionó el repositorio para la reproducción.

Estoy de acuerdo. Es un tema muy molesto. También bloquea las pruebas si está probando si la transición ha sido abortada

Nuestras declaraciones de captura para transiciones que pueden provocar un aborto verifican explícitamente este error. Aunque sigue siendo un dolor ...

La pregunta a responder es si alguna vez nos preocupamos por TransitionAbortedError , ¿puede suceder de una manera que queramos informar de la excepción? Puede ser útil saber cuándo se está redirigiendo al usuario (este suele ser un comportamiento inesperado para el usuario o una mala experiencia de usuario, el usuario debe saber a dónde se dirige cuando hace clic en algo).

En muchos casos, debe considerar a dónde se dirige el usuario antes de poder redirigirlo y usar las redirecciones como último recurso. Creo que esos errores "espurios" que se informan son en realidad indicaciones de un mal diseño de UX.

Por supuesto que estoy afectado por este problema porque en muchos casos no sabes cómo dirigir al usuario hasta después de que se haya disparado el gancho del modelo ... como un campo que ha cambiado en el backend. Sigue siendo bueno dar comentarios a los usuarios sobre la transición en lugar de redirigirlos en silencio.

Por eso creo que es bueno que se lancen, da la oportunidad de alertar al usuario sobre una transición inesperada y recordarle lugares donde se puede mejorar su experiencia de usuario.

@ezpuzz La autorización por niveles (no la autenticación) es un área con la que siempre nos encontramos. Almacenamos la transición para más adelante para que podamos proporcionar una buena UX y aliviar el dolor de los desarrolladores al implementar rutas. No sabemos qué rutas necesitan un permiso elevado hasta que se golpean, en cuyo caso abortamos y pedimos credenciales elevadas antes de volver a intentarlo. Una afirmación general de que en muchos casos es una mala experiencia de usuario es un nombre inapropiado.

También a la nota, este error se eleva en un bloque asíncrono, no se descarga en rsvp.on ( 'error'

Además, si no anula RSVP.on('error') este código se ejecuta y se traga el error: https://github.com/emberjs/ember.js/blob/master/packages/@ember/ -internals / runtime / lib /ext/rsvp.js

@ James1x0 lo siento, lo que quise decir es que hay casos útiles de lanzar la excepción (uno identifica los puntos

En ese caso podríamos mejorar la utilidad del error aquí: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition-aborted-error.ts

pasando más sobre la transición aquí: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition.ts#L401

De lo contrario, podría ignorarse, como se mencionó en mi último comentario.