J’aimerais beaucoup avoir des conseils sur la marche à suivre ici, mais j’ai aussi quelques idées sur la façon dont cela pourrait être mieux géré.
Ce qui pourrait se passer
Une théorie est que notre serveur a peut-être été identifié par YouTube comme potentiellement dédié au « farming » de vidéos musicales, et que nous subissons des limitations ou un blocage.
Nous sommes un tout petit forum sans prétention au Royaume-Uni avec un trafic modeste, mais nous avons quelques fils de discussion (en réalité un seul divisé en deux en raison de sa taille) contenant plus de 10 000 + 2 000 messages de vidéos musicales. C’est une chaîne musicale où le prochain poster ajoute simplement une chanson liée, souvent de manière tangentielle, au message précédent.
Nous avons bien sûr d’autres fils avec des liens YouTube, mais celui-ci est particulièrement (~100 %) dense en musique.
Suite à une reconstruction (« rebake ») ce week-end, je suppose que YouTube a analysé l’activité du Oneboxer tentant de récupérer les en-têtes pour de nombreuses vidéos musicales, et que son algorithme nous a mis au coin.
J’ai ensuite réessayé de reconstruire les messages, ce qui a probablement confirmé les soupçons de YouTube selon lesquels tout ce que nous faisons depuis cette adresse IP est de tenter de télécharger des vidéos musicales.
Peut-être lié à Digital Ocean
En cherchant sur Google les erreurs 429 sur YouTube et en ignorant tous les résultats liés à l’API YouTube, on finit par aboutir à un groupe de problèmes similaires qui indiquent tous que leurs adresses IP ont été mises sur liste grise, liste noire ou bannies en raison de leur hébergement sur des serveurs virtuels. Le nom de Digital Ocean a été spécifiquement mentionné.
La suggestion est que YouTube pourrait « bannir » une série d’adresses IP et que d’autres serveurs légitimes sont souvent victimes de dommages collatéraux.
Voici un tel problème et une solution potentielle :
https://support.google.com/youtube/thread/21697789?hl=en
Et en voici un autre provenant d’un développeur sur medium.com qui travaille sur l’API embed.ly :
https://support.google.com/youtube/thread/21939228?hl=en
La résolution suggérée dans le premier message était de désactiver IPv6 sur le droplet.
Quelqu’un sait-il si cela semble plausible, ou si cela pourrait causer des problèmes ?
J’ai attendu pour le faire pour le moment afin de pouvoir collecter toutes les autres données nécessaires pour faciliter la résolution.
Ce qui devrait se passer
Premièrement, je comprends que la réaction ici soit probablement que mon expérience est un cas limite et qu’aucun changement n’est nécessaire.
Je peux le comprendre. Mais si @marcozambi et moi avons découvert le même problème dans un laps de temps relativement court, cela suggère que d’autres pourraient le rencontrer. Peut-être que YouTube est devenu récemment plus rigoureux dans sa surveillance des intégrations ?
Je vous demande de garder à l’esprit que, pour le moment, mon forum est dans une impasse totale. J’ai des dizaines de milliers de liens qui n’ont pas pu être intégrés via Onebox, mais je ne sais pas où ils se trouvent. Je ne vois qu’une reconstruction totale pour les trouver tous, ce qui attirera presque certainement davantage l’attention négative de YouTube.
À tout le moins, Onebox ne peut pas échouer silencieusement lorsqu’il rencontre une erreur de limite de taux. Il doit alerter les administrateurs et, si possible, mettre en pause le processus qui a déclenché le problème de limite de taux.
Options pour alerter le propriétaire du forum
Je ne pense pas que ce soit facile. Pas du tout.
Je vois Onebox comme jouant plusieurs rôles distincts :
a) il construit des Oneboxes en temps réel lors de la rédaction des messages,
b) il répond aux reconstructions de messages anciens (avec souvent des liens déjà connus) en arrière-plan et de manière silencieuse,
c) il est sollicité pour gérer des masses de messages de tâches en arrière-plan lors d’une migration ou d’une reconstruction.
Si une erreur de limite de taux survenait lors du scénario a), l’auteur remarquerait que le Onebox ne s’est pas étendu et pourrait se plaindre aux administrateurs du forum — cela pourrait être remarqué. Je suppose qu’il est également possible de capturer l’erreur unique lors de la rédaction et d’envoyer une erreur ou un message aux administrateurs ?
Dans le scénario b), l’échec peut survenir lors du traitement en arrière-plan du message, et il faudrait donc soit réessayer, soit, si le nombre de réessais est atteint, marquer l’échec et notifier les administrateurs du forum.
Dans le scénario c), le contexte plus large de nombreuses échecs se produisant simultanément devrait être connu. Pour le moment, je ne crois pas qu’il existe un contrôle global du processus de reconstruction des messages permettant de reconnaître que 10 000 erreurs 429 renvoyées par Onebox constituent un problème plus important que l’envoi de 10 000 messages individuels aux administrateurs.
En réalité, un échec de ce type signifierait que tous les appels à Onebox pour l’expansion de vidéos YouTube (et peut-être d’autres fournisseurs également) devraient être mis en pause jusqu’à ce que nous ne soyons plus limités par le taux.
Approches alternatives
Limiter les taux des requêtes sortantes
Je suppose que l’adage « mieux vaut prévenir que guérir » pourrait dicter la mise en place d’un limiteur de taux Discourse devant les requêtes, afin que Discourse retarde les requêtes selon certaines configurations.
Cela perturberait gravement les reconstructions et les migrations.
Assistant Onebox
Peut-être avons-nous tous besoin de relations commerciales avec des organisations qui mettent en cache et font proxy des intégrations, comme celle utilisée par @merefield dans son plugin Onebox Assistant ?
Mettre le « bot » sur liste blanche
Pourrions-nous trouver un moyen de mettre le « bot » Discourse sur liste blanche auprès de YouTube ? Probablement trop ouvert aux abus.
API YouTube
Tout comme Onebox le fait avec Twitter, pourrions-nous utiliser l’API YouTube si les limites de taux sont plus élevées ?
