Me encantaría recibir consejos sobre qué hacer en este caso, pero también tengo algunas ideas sobre cómo podría manejarse mejor.
Lo que podría estar sucediendo
Una teoría es que nuestro servidor pudo haber sido identificado por YouTube como un posible granjero de videos musicales y, por eso, estamos siendo limitados o bloqueados.
Somos un foro realmente insignificante en el Reino Unido con un tráfico modesto, pero tenemos un par de hilos (en realidad uno dividido en dos debido a su tamaño) con 10.000 + 2.000 publicaciones de videos musicales. Es una cadena musical donde el siguiente usuario simplemente publica una canción relacionada, a menudo de manera tangencial, con la publicación anterior.
Por supuesto, tenemos otros hilos con enlaces de YouTube, pero este en particular es (~100 %) denso en contenido musical.
Tras una reconstrucción (rebake) el fin de semana, supongo que YouTube analizó la actividad del Oneboxer al intentar obtener encabezados de muchos videos musicales y su algoritmo nos puso en la lista de sospechosos.
Posteriormente, volví a intentar reconstruir las publicaciones, lo que presumiblemente confirmó las sospechas de YouTube de que lo único que hacemos desde esta dirección IP es intentar descargar videos musicales.
Podría estar relacionado con Digital Ocean
Así que, al buscar en Google los errores 429 en YouTube e ignorando todos los resultados relacionados con la API de YouTube, finalmente se llega a un grupo de problemas similares que indican que sus direcciones IP han sido incluidas en listas grises, negras o prohibidas como resultado de estar en servidores virtuales. El nombre de Digital Ocean fue mencionado específicamente.
La sugerencia es que YouTube podría “prohibir” una serie de direcciones IP y que otros servidores legítimos a menudo se ven afectados como daño colateral.
Aquí hay un problema y una posible solución de este tipo:
https://support.google.com/youtube/thread/21697789?hl=en
Y aquí hay otro de un desarrollador en medium.com que trabaja en la API de embed.ly:
https://support.google.com/youtube/thread/21939228?hl=en
La resolución sugerida en la primera publicación fue deshabilitar IPv6 en el droplet.
¿Alguien sabe si eso suena plausible o si podría causar algún problema?
He pospuesto hacer esto por el momento para poder recopilar cualquier otro dato que pueda ser necesario para ayudar a resolver el problema.
Lo que debería suceder
En primer lugar, entiendo que la reacción aquí probablemente sea que mi experiencia es un caso excepcional y que no se necesita ningún cambio.
Puedo entenderlo. Pero si @marcozambi y yo hemos encontrado el mismo problema en un período relativamente corto, entonces sugiere que podría ser algo que otros también verán. ¿Quizás YouTube se ha vuelto más estricto recientemente en su control de las incrustaciones?
Les pediría que recuerden que, en este momento, mi foro está en un limbo completo. Tengo decenas de miles de enlaces que no se han incrustado correctamente mediante Onebox, pero no sé dónde están y solo se me ocurre hacer una reconstrucción total para encontrarlos todos, lo que casi con seguridad atraerá más atención negativa por parte de YouTube.
Como mínimo, Onebox no puede fallar en silencio cuando se encuentra con un error de límite de tasa. Debe alertar a los administradores y, cuando sea posible, pausar el proceso que desencadenó el problema de límite de tasa.
Opciones para alertar al propietario del foro
No creo que esto sea fácil. En absoluto.
Veo que Onebox desempeña varios roles claramente diferentes:
a) Construye Oneboxes en tiempo real a medida que se redactan las publicaciones.
b) Responde a reconstrucciones de publicaciones antiguas (a menudo con enlaces ya conocidos) en segundo plano y de forma silenciosa.
c) Se le pide que maneje grandes cantidades de trabajos en segundo plano durante una migración o reconstrucción.
Si ocurriera un error de límite de tasa durante el escenario a), el autor notaría que el Onebox no se expandió y podría quejarse a los administradores del foro; podría ser detectado. Supongo que también es posible capturar el único error durante la redacción y enviar un error o mensaje a los administradores.
En el escenario b), el fallo podría ocurrir durante el procesamiento en segundo plano de la publicación y, por lo tanto, necesitaría reintentarse o, si se alcanzara un número máximo de reintentos, podría fallarse y notificar a los administradores del foro.
En el escenario c), sería necesario conocer el contexto más amplio de muchos fallos ocurriendo al mismo tiempo. En este momento, no creo que exista ningún control general del proceso de reconstrucción de publicaciones de modo que 10.000 errores 429 devueltos por Onebox puedan reconocerse como un problema mayor que enviar 10.000 mensajes individuales a los administradores.
En la práctica, un fallo como ese significaría que todas las llamadas a Onebox para la expansión de videos de YouTube (y posiblemente de otros proveedores también) deberían suspenderse hasta que ya no estemos sujetos a límites de tasa.
Enfoques alternativos
Limitar las solicitudes salientes
Supongo que el principio de que la prevención es mejor que la cura podría dictar que se coloque un limitador de tasa de Discourse frente a las solicitudes, de modo que Discourse retenga las solicitudes según una configuración definida.
Esto causaría caos en las reconstrucciones y migraciones.
Asistente de Onebox
¿Quizás todos necesitamos relaciones comerciales con organizaciones que almacenan en caché y proxy las incrustaciones, como la utilizada por @merefield en su complemento Onebox Assistant?
Listar en blanco al ‘bot’
¿Podríamos encontrar una manera de incluir al ‘bot’ de Discourse en la lista blanca de YouTube? Probablemente sea demasiado propenso a abusos.
API de YouTube
Al igual que Onebox lo hace con Twitter, ¿quizás podríamos usar la API de YouTube si sus límites de tasa son mayores?