Desde hace unos días (diría que justo después de actualizar a Discourse 2.5 beta 5, y continúa en la beta 6, aunque podría ser una coincidencia), la incrustación de videos de YouTube funciona de forma intermitente. Después de varias horas sin funcionar, simplemente vuelve a incrustar correctamente.
Desde ayer, dejó de funcionar por completo.
No veo ningún error sospechoso específico en los registros del foro.
¿Podría ser un problema de tiempo de espera? ¿Hay alguna forma de investigar esto específicamente?
Encontré algo extraño al examinar el tráfico generado al solicitar una recocción de una publicación que contiene un enlace de YouTube.
La solicitud falla con el error 404.
Un poco más de detalle adicional.
Estoy ejecutando Discourse 2.5.0.beta6 actualizado al commit 2d880b42a3 (reconstruido justo antes de enviar este mensaje).
Al crear una nueva publicación con un enlace de YouTube, desde la consola de Google Chrome veo un error adicional justo antes del 404 para la solicitud GET a onebox, que hace referencia a un error de registro del Service Worker.
Quiero señalar que cualquier onebox funciona, excepto YouTube.
si repito la simple llamada GET (pasando las cabeceras y demás como se espera) a /onebox?url=…, simplemente obtengo el error HTML 404.
si repito, en el servidor, la solicitud que hace onebox, copiándola del código Ruby de youtube_onebox.rb, es decir, curl 'curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' para uno de los videos no incrustados, parece funcionar perfectamente.
La llamada en realidad devuelve: {"author_name":"AstronautiCAST","version":"1.0","height":270,"author_url":"https:\/\/www.youtube.com\/user\/AstronautiCAST","provider_name":"YouTube","provider_url":"https:\/\/www.youtube.com\/","thumbnail_height":360,"width":480,"html":"\u003ciframe width=\"480\" height=\"270\" src=\"https:\/\/www.youtube.com\/embed\/Xl-PTTeRsik?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen\u003e\u003c\/iframe\u003e","type":"video","thumbnail_width":480,"title":"Loading cargo into HTV-9 Konutori","thumbnail_url":"https:\/\/i.ytimg.com\/vi\/Xl-PTTeRsik\/hqdefault.jpg"}root@fait-2020:/var/discourse#
lo cual contiene todo lo que onebox necesita para la incrustación.
@Falco, de verdad siento molestarte, pero la falta de oneboxing de YouTube está afectando gravemente la experiencia de usuario en nuestro foro.
Ayer intenté varias cosas, como leer el código fuente (para entender en qué etapa y bajo qué condición se produce el retorno de un 404 por parte del onebox) e incluso llegué a clonar el foro de producción actual en un nuevo droplet de Digital Ocean.
Leer el código no me ayudó mucho, principalmente por mi falta de conocimientos reales sobre la plataforma.
Sigue quedando una pregunta al respecto: ¿se registra en algún lugar el proceso de oneboxing? Sería muy útil entender el error que hace que onebox desista y devuelva un 404.
El droplet clonado fue un intento para verificar si la IP del servidor de producción estaba bloqueada por YouTube y, al mismo tiempo, si había algún problema relacionado con el nombre de dominio que utilizamos.
Bueno, aunque la dirección IP y el nombre de dominio eran diferentes, el oneboxing de YouTube no funcionaba.
Realmente espero que alguien pueda sugerirme al menos una forma de rastrear qué hace el oneboxing.
Tengo la causa raíz: YouTube ha bloqueado nuestra IP, pero no está claro por qué, ya que en el momento en que ocurrió no estábamos realizando ninguna reconstrucción masiva o similar.
Pregunta para @Falco o @codinghorror: ¿la instalación de la versión 2.5.0beta 5 o 6 activó alguna reconstrucción, lo que habría superado el límite de solicitudes?
Gracias a todos por las respuestas.
Sin embargo, sigue sin estar claro para mí por qué, si imito la solicitud que realiza el motor onebox (o al menos espero que sea así. ¿Es @Falco?), obtengo una respuesta JSON con una respuesta adecuada y no un error 429.
¿Existe otra solicitud realizada por Onebox que obtiene un 429 antes de realizar la solicitud según mi captura de pantalla, que es curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik'?
No hace falta decir que estas solicitudes se realizaron desde el mismo servidor que ejecuta Discourse (por lo tanto, misma IP de salida).
Un hallazgo interesante tras un fin de semana de resolución de problemas.
Quizás esto sea algo en lo que quieras echar un vistazo, @Falco o @codinghorror.
Por el momento, al leer el código fuente de youtube_onebox.rb, veo que admite 3 URLs de las que se extrae el ID del video:
http://youtu.be/<videoid>
https://www.youtube.com/embed/<videoid>
https://www.youtube.com/watch?v=<videoid>
Cada intento de generar una onebox para videos con enlaces en los formatos 1 y 3 falla, devolviendo un error 404 (lo cual creo que está relacionado con que nuestra IP haya sido bloqueada).
Cuando intento incrustar enlaces con el formato 2, ¡funciona!
Me pregunto si y cómo esto podría estar relacionado con el hecho explicado en esta publicación.
Sería muy útil tener una comprensión (y un registro) del funcionamiento interno de onebox (es decir, qué llamada(s) exacta(s) se realiza(n) a YouTube)…
Vuelvo por aquí para cerrar este hilo.
Ayer YouTube eliminó nuestra prohibición y volvemos al negocio.
Hay un par de puntos que, en mi opinión, sería interesante entender de todos modos:
¿Podría onebox registrar los detalles en caso de que falle el oneboxing? Sería muy útil para entender exactamente por qué falla el oneboxing.
Dado que el único elemento necesario para hacer oneboxing de videos de YouTube es el ID del video, ¿no sería buena idea intentar extraer datos de cada uno de los 3 tipos de URL antes de devolver un 404 (como se mencionó arriba, la URL /embed/ nunca dejó de funcionar de alguna manera, incluso cuando estábamos prohibidos).
¡Gracias a todos los que respondieron a mis preguntas pánicas!
¡Esto!!! (es una muy buena idea, ya lo había mencionado antes)
Supongo que parte del desafío aquí es que, si el destino devuelve una página sin etiquetas og, Onebox no sabrá que esto se debió a alguna redirección. Sin embargo, eso podría registrarse (“ONEBOX: no se encontraron etiquetas og”) y todos los errores que provocan oneboxes en blanco deberían registrarse definitivamente.
tl;dr Me gustaría añadir que estamos experimentando lo que parece ser el mismo problema. Si existe un problema de límite de tasa debido a algún cambio reciente, creo que otros usuarios comenzarán a experimentarlo durante la migración, la regeneración de publicaciones o quizás simplemente debido a un foro muy activo. El hecho de que el onebox aparentemente falle en silencio significa que estos problemas no son visibles hasta que los usuarios comienzan a quejarse de que faltan los oneboxes de YouTube.
Antecedentes
Estamos en la versión 2.6.0.beta 1
Los usuarios recibían mensajes sobre contenido no seguro. Tras investigar, Chrome parecía estar quejándose de imágenes enlazadas desde sitios HTTP. Así que configuré Discourse para descargar todas las imágenes y medios y servirlos a través de HTTPS.
Una vez que cambié la configuración, esto significó realizar una regeneración (re-bake) de las publicaciones históricas. Desde esa regeneración, un gran bloque de videos de YouTube que antes aparecían como onebox ahora han vuelto a mostrarse como URLs enlazadas.
Tenemos un hilo de 10,000 publicaciones que consiste exclusivamente en respuestas con videos de YouTube, y todas las publicaciones son URLs y no oneboxes.
Durante la regeneración, todos los trabajos en cola se procesaron de forma orgánica, por lo que no se trata de trabajos atascados en una cola de trabajos eliminados.
No he visto los mismos mensajes de error que describió @marcozambi, pero creo que también estamos alcanzando un límite de tasa.
¿Qué he intentado?
En apoyo de esta teoría del límite de tasa, un pequeño fragmento de código que escribí para regenerar publicaciones funcionó (generó onebox) para los primeros 80+ videos de YouTube en un hilo, pero luego dejó de convertir los videos restantes.
En ese punto, incluso editar la publicación, hacer un pequeño cambio y volver a guardar no obligó a que la URL se expandiera como onebox. Al mismo tiempo, todas las colas estaban vacías o tenían trabajos menores que se procesaban instantáneamente, como esperaba.
Los intentos de volver a ejecutar ese código durante un período de 30 minutos no lograron forzar la generación de onebox de los enlaces. No creo que 80 sea un número mágico aquí, sino simplemente lo que estaba disponible dentro de la cuota que teníamos.
@marcozambi mencionó que el formato de enlace de YouTube /embed/ funcionó cuando otros fallaron, así que modifiqué el código para usar una búsqueda y reemplazo con expresiones regulares de los enlaces de YouTube y convertirlos al formato /embed/.
El código funcionó.
Volver a ejecutar el código solo para regenerar las publicaciones nuevamente no logró convertirlos en representaciones de onebox.
Mi plan es experimentar con una tarea que convierta todos los enlaces de YouTube en el hilo grande al formato /embed/ de YouTube. Si eso falla o alcanzamos un límite de tasa más alto, entonces revisaré el Onebox Assistant de @merefield.
OK, definitivamente hay algo extraño ocurriendo y parece estar relacionado con la limitación de tasa.
No estoy seguro de si nos están limitando la tasa porque realicé una recocción masiva y nos han puesto en el rincón del castigo, o si estamos activando límites que otros también verán.
Parece que la incrustación (Oneboxing) de videos de YouTube tiene un límite y, una vez alcanzado, la incrustación falla en silencio.
Siento que esto debe cambiarse, por razones que espero sean obvias, pero específicamente para cualquier persona que realice una migración o recocción y no tenga idea de que muchos enlaces de YouTube que antes se expandían o que nunca se expandieron ahora son simplemente URLs normales.
@marcozambi mencionó más arriba que el formato de URL de YouTube que incluye /embed/ antes del ID del video funciona cuando otros formatos fallan (presuntamente debido a un problema de limitación de tasa).
Aquí hay un video que ilustra bien ese fenómeno.
Cuando se capturó esta grabación de pantalla, no había trabajos saturando las colas y el foro funcionaba correctamente en otros aspectos.
Antes de este video, los enlaces de YouTube ya habían comenzado a fallar al ser expandidos por OneBox.
Lo que verás es la ventana de redacción donde OneBox falla al expandir un enlace de YouTube en el formato https://youtu.be/<video-id>.
Luego cambio el formato a https://youtube.com/embed/<video-id> y OneBox lo expande correctamente.
Después intento nuevamente con el formato original y falla.
Durante esta captura de video, registré las pestañas de consola del navegador y de red. Reconozco que el problema seguramente está entre nuestro servidor y YouTube, y no entre mi navegador y nuestro servidor, pero las incluyo a continuación por si resultan útiles.
(disculpas por el aspecto muy alejado de la imagen; espero que sean visibles al hacer zoom)
No estoy convencido de que el formato de enlace /embed/ sea una panacea en este caso.
Creo que parece ser una ruta con límites de tasa separados, de modo que cuando la ruta https://youtu.be/<video-id> alcanza su límite, existe otra ruta con un límite independiente en https://youtube.com/embed/<video-id>.
La evidencia de que ambas rutas están limitadas proviene de una utilidad que escribí para cambiar el formato de los incrustados de YouTube en un hilo monstruoso de 10 mil publicaciones que presentaba respuestas de video de YouTube en un 99%.
En ese momento, Onebox ya estaba fallando al expandir los enlaces con el formato https://youtu.be/<video-id>.
Mi utilidad, que cambiaba la URL del video de YouTube al formato https://youtube.com/embed/<video-id>, se ejecutó sobre las primeras 3000 publicaciones del hilo.
Funcionó bien para las primeras 1108 y luego, aunque cambió el formato de las siguientes ~1900 publicaciones, estas no fueron expandidas por Onebox.
Durante este tiempo, se generaron muchos trabajos (mi código usaba post.revise) y todos se procesaron sin errores ni reintentos.
Anecdóticamente, noté que el procesamiento de trabajos parecía acelerarse drásticamente en cierta etapa. Supongo que esto podría deberse a que el código de Onebox estaba recibiendo rápidamente algún tipo de error de YouTube, pero no lo cronometré y podría haber sido varias cosas.
Estaría encantado de intentar proporcionar evidencia más detallada aquí, pero no estoy seguro de qué puedo hacer sin instrumentar la gema Onebox.
Soy un hacker y no un experto en Ruby, pero estaría encantado de seguir algunas instrucciones de alto nivel.
Ejecutar algunos scripts repetitivos de curl breves desde la línea de comandos del servidor con el mismo agente de usuario podría permitirle aislar un problema de límite de velocidad.
Estoy de acuerdo en que el método alternativo probablemente funcione solo porque es un conteo separado.
Aquí hay más resultados. Tenga en cuenta que hay muchas suposiciones en el siguiente post, basadas en la falta de conocimiento real.
Seguiré este post con mi opinión sobre lo que está sucediendo y lo que debería ocurrir.
Gracias por la respuesta, Robert.
Tenga en cuenta que la Oneboxing de videos usando la ruta /watch fallaba (¡y sigue fallando!) cuando lo intenté, por lo que no necesité un bucle para forzar el fallo.
Así que una suposición que he hecho es que el user-agent que usa Onebox es Discourse Forum Onebox v2.6.0.beta1, basado en este código…
Elegí un video al azar e intenté usar curl para leer las cabeceras.
Lo hice desde dentro del contenedor Docker en mi sitio en vivo, lo que produjo la siguiente respuesta.
Así que me están enviando un código de respuesta 429 “demasiadas solicitudes”, pero sin enviar una cabecera retry-after — cesar y desistir sin negociación.
De cualquier manera, si esto es lo que está viendo Onebox, está ignorando la respuesta o, al menos, no sé dónde buscar si se está registrando.
Aunque esto podría ser algo legítimo de hacer para un único 429, ver muchas respuestas 429 en un período de tiempo muy corto no puede ser ignorado.
Resultado del tercer curl - esta vez usando la ruta /embed/
Para completar, intenté inmediatamente obtener el mismo video, pero esta vez usando la ruta /embed/.
El plugin lazy-yt parece reescribir las URLs en formato /watch
No estoy seguro de si esto es de alguna significancia, pero… ¿el plugin incrustado lazy-yt está habilitado por defecto? Lo noté en mi instalación de desarrollo.
Parece que hace un monkey patch al método to_html del Oneboxer de YouTube.
No sé si es significativo, pero el método to_html del Onebox original devuelve el formato de URL /embed/…
Mientras que el plugin lazy-yt usa el formato de URL /watch?v=.
¿Hay algo más que pueda hacer para mostrar que hay un problema que necesita alguna forma de atención? El siguiente post explicará lo que creo que es la causa raíz.
