Depuis quelques jours (je dirais juste après la mise à jour vers Discourse 2.5 beta 5 – et cela continue sur la beta 6 – mais cela peut très bien être une coïncidence), l’intégration de vidéos YouTube fonctionne de manière intermittente. Après quelques heures sans fonctionner, elle reprend normalement.
Depuis hier, elle ne fonctionne plus du tout.
Je ne vois aucune erreur suspecte spécifique dans les journaux du forum.
Pourrait-il s’agir d’un problème de délai d’attente ? Existe-t-il un moyen d’enquêter spécifiquement là-dessus ?
J’ai remarqué quelque chose d’étrange en examinant le trafic généré par la demande de régénération d’un post contenant un lien YouTube.
La demande échoue avec l’erreur 404.
Un peu plus de détails.
Je exécute Discourse 2.5.0.beta6 mis à jour vers le commit 2d880b42a3 (reconstruit juste avant l’envoi de ce message).
Lors de la création d’un nouveau message avec un lien YouTube, depuis la console Google Chrome, j’observe une erreur supplémentaire juste avant le 404 pour la requête GET vers onebox, faisant référence à une erreur d’enregistrement du Service Worker.
Je tiens à souligner que tous les oneboxes fonctionnent, sauf celui de YouTube.
Le navigateur ne peut pas vous fournir la vraie raison pour laquelle une onebox échoue. Vous devez essayer d’effectuer une requête similaire depuis votre serveur.
si je répète l’appel GET simple (en transmettant les en-têtes et autres éléments comme prévu) vers /onebox?url=…, je reçois simplement une erreur HTML 404.
si je répète, côté serveur, la requête que onebox effectue, en la copiant depuis le code Ruby de youtube_onebox.rb, à savoir curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' pour l’une des vidéos non intégrées, cela semble fonctionner parfaitement.
L’appel renvoie effectivement : {"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#
ce qui contient tout ce dont onebox a besoin pour l’intégration.
@Falco, vraiment désolé de te déranger, mais l’absence de prévisualisation YouTube (oneboxing) nuit gravement à l’expérience utilisateur de notre forum.
Hier, j’ai essayé plusieurs choses, comme lire le code source (pour comprendre à quel stade et dans quelles conditions un 404 peut être renvoyé par le oneboxing), jusqu’à cloner le forum de production actuel sur un nouveau droplet Digital Ocean séparé.
La lecture du code n’a pas vraiment aidé, principalement en raison de mon manque de connaissances réelles sur la plateforme.
Une question reste en suspens à ce sujet : le processus de oneboxing est-il enregistré quelque part ? Ce serait si utile de comprendre l’erreur qui pousse le oneboxing à abandonner et à renvoyer un 404.
Le droplet cloné était une tentative pour vérifier si l’adresse IP du serveur de production était bannie par YouTube et, en même temps, s’il y avait un problème lié au nom de domaine que nous utilisons.
Eh bien, même si l’adresse IP et le nom de domaine étaient différents, le oneboxing YouTube ne fonctionnait pas.
J’espère vraiment que quelqu’un pourra me suggérer au moins un moyen de tracer ce que fait le oneboxing.
J’ai identifié la cause racine : YouTube a banni notre adresse IP, mais la raison n’est pas claire car, au moment où cela s’est produit, nous ne procédions à aucune re-cuisson massive ou opération similaire.
Question pour @Falco ou @codinghorror : l’installation de la version 2.5.0beta 5 ou 6 a-t-elle déclenché une re-cuisson, ce qui aurait dépassé la limite de requêtes ?
Merci à tous pour vos réponses.
Cependant, il reste unclear pour moi pourquoi, si j’émule la requête que le moteur onebox effectue (ou du moins c’est ce que je suppose être le cas. Est-ce @Falco ?), j’obtiens une réponse JSON avec une réponse appropriée, et pas une erreur 429.
Y a-t-il une autre requête effectuée par Onebox qui renvoie une erreur 429, avant d’exécuter la requête comme dans mon capture d’écran, qui est curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' ?
Il va de soi que ces requêtes ont été effectuées depuis le même serveur exécutant Discourse (donc même adresse IP sortante).
Une découverte intéressante après un week-end de dépannage.
Cela pourrait peut-être mériter votre attention, @Falco ou @codinghorror ?
Pour l’instant, en lisant le code source de youtube_onebox.rb, je constate qu’il prend en charge 3 formats d’URL à partir desquels l’identifiant de la vidéo est extrait :
http://youtu.be/<videoid>
https://www.youtube.com/embed/<videoid>
https://www.youtube.com/watch?v=<videoid>
Toutes les tentatives de créer un onebox pour des vidéos dont les liens sont au format 1. et 3. échouent, le onebox renvoyant une erreur 404 (ce qui, selon moi, est lié au fait que notre adresse IP est bannie).
Lorsque j’essaie d’intégrer des liens au format 2., cela fonctionne !
Je me demande si et comment cela pourrait être lié à l’explication donnée dans ce post.
Une meilleure compréhension (et des logs) du fonctionnement interne de onebox (c’est-à-dire quel(s) appel(s) exact(s) est/sont effectué(s) vers YouTube) serait extrêmement utile…
Je reviens ici pour clore ce fil.
Hier, YouTube a levé notre bannissement et nous sommes de nouveau opérationnels.
Il y a quelques points qui, selon moi, mériteraient d’être compris de toute façon :
Onebox pourrait-elle enregistrer les détails en cas d’échec de l’encapsulation ? Cela serait très utile pour comprendre exactement pourquoi l’encapsulation échoue.
Puisque le seul élément nécessaire pour encapsuler les vidéos YouTube est l’ID de la vidéo, ne serait-il pas judicieux d’essayer d’extraire des données à partir de chacun des 3 types d’URL avant de renvoyer une erreur 404 (comme mentionné ci-dessus, l’URL /embed/ n’a jamais cessé de fonctionner d’une manière ou d’une autre, même lorsque nous étions bannis).
Merci à tous ceux qui ont répondu à mes questions paniquées !
C’EST ÇA !!! (c’est une excellente idée que j’ai déjà mentionnée)
Je suppose qu’une partie du défi ici réside dans le fait que si la cible renvoie une page sans balises og, Onebox ne saura pas que cela est dû à une redirection. Cependant, cela pourrait être journalisé (« ONEBOX : aucune balise og trouvée ? ») et toutes les erreurs entraînant des oneboxes vides devraient absolument être journalisées.
tl;dr : J’aimerais ajouter que nous rencontrons apparemment le même problème. S’il s’agit d’une limite de débit due à un changement récent, je pense que d’autres utilisateurs commenceront à en subir les conséquences lors de la migration, du re-baking des publications ou simplement en raison d’un forum très actif. Le fait que le onebox échoue apparemment sans émettre d’alerte signifie que ces problèmes ne deviennent visibles que lorsque les utilisateurs se plaignent de l’absence des oneboxes YouTube.
Contexte
Nous sommes sur la version 2.6.0.beta 1
Les utilisateurs recevaient des messages concernant du contenu non sécurisé. Après investigation, Chrome semblait signaler des images liées à partir de sites HTTP. J’ai donc configuré Discourse pour télécharger toutes les images et tous les médias et les servir via HTTPS.
Une fois ce paramètre modifié, cela a nécessité un re-baking des publications historiques. Depuis ce re-baking, un grand nombre de vidéos YouTube qui étaient auparavant converties en onebox sont désormais retournées à leur simple URL.
Nous avons un seul fil de discussion de 10 000 messages composé uniquement de réponses contenant des vidéos YouTube, et tous les messages affichent des URLs au lieu de oneboxes.
Pendant le re-baking, tous les travaux en file d’attente ont été traités de manière organique, donc il ne s’agit pas de travaux bloqués dans une file d’attente de travaux supprimés.
Je n’ai pas vu les mêmes messages d’erreur que ceux décrits par @marcozambi, mais je pense que nous atteignons également une limite de débit.
Qu’ai-je essayé ?
Pour étayer cette théorie de la limite de débit, un petit bout de code que j’ai écrit pour re-baker les messages a fonctionné (conversion en onebox) pour les 80 premières vidéos YouTube d’un fil, puis a échoué à convertir les vidéos restantes.
À ce stade, même la modification d’un message, l’ajout d’une petite correction et sa réenregistrement n’ont pas forcé l’URL à être « étendue » en onebox. Dans le même temps, toutes les files d’attente étaient vides ou contenaient des travaux mineurs traités instantanément, comme je m’y attendais.
Les tentatives de réexécution de ce code sur une période de 30 minutes n’ont pas réussi à forcer la conversion des liens en onebox. Je ne pense pas que 80 soit un nombre magique ici, c’est simplement ce qui était disponible dans notre quota.
@marcozambi a mentionné que le format de lien YouTube /embed/ fonctionnait alors que d’autres échouaient. J’ai donc modifié le code pour utiliser une recherche et un remplacement par expression régulière afin de convertir les liens YouTube en format /embed/.
Le code a fonctionné.
La réexécution du code pour simplement re-baker à nouveau les messages n’a pas réussi à les convertir en représentations onebox.
Mon plan est d’expérimenter avec une tâche qui convertit tous les liens YouTube du grand fil de discussion au format YouTube /embed/. Si cela échoue ou si nous atteignons une limite de débit plus élevée, j’examinerai l’Assistant Onebox de @merefield.
OK, il se passe certainement quelque chose d’étrange et cela semble lié à une limitation du débit.
Je ne sais pas si nous sommes limités en débit parce que j’ai effectué un rebaking massif et que nous avons été mis au coin, ou si nous dépassons des limites que d’autres rencontreront.
L’Oneboxing des vidéos YouTube semble avoir une limite, et une fois cette limite atteinte, l’Oneboxing échoue silencieusement.
Je pense que cela doit être modifié pour des raisons qui devraient être évidentes, mais surtout pour toute personne effectuant une migration ou un rebaking qui ne saura pas que de nombreux Oneboxes non développés ou déjà développés sont désormais de simples URL brutes.
@marcozambi a mentionné ci-dessus que le format d’URL YouTube contenant /embed/ avant l’ID de la vidéo fonctionne lorsque les autres formats échouent (présumément en raison d’un problème de limitation du débit).
Voici une vidéo qui illustre bien ce phénomène.
Lors de l’enregistrement de cette capture d’écran, il n’y avait aucun processus bloquant les files d’attente et le forum fonctionnait par ailleurs correctement.
Avant cette vidéo, les liens YouTube avaient déjà commencé à échouer lors de l’expansion par OneBox.
Vous verrez la fenêtre de composition où l’Onebox échoue à développer un lien YouTube au format https://youtu.be/<video-id>.
Je change ensuite le format en https://youtube.com/embed/<video-id> et l’Onebox le développe.
J’essaie à nouveau avec le format original et cela échoue.
Pendant l’enregistrement de cette vidéo, j’ai surveillé les onglets console du navigateur et réseau. Je reconnais que le problème se situe sûrement entre notre serveur et YouTube plutôt qu’entre mon navigateur et notre serveur, mais je les inclus ci-dessous au cas où ils seraient utiles.
(désolé pour le niveau de zoom réduit de l’image - j’espère qu’elles seront visibles une fois zoomées)
Je ne suis pas convaincu que le format de lien /embed/ soit une panacée ici.
Je pense qu’il semble s’agir d’une route disposant de limites de débit distinctes, de sorte que lorsque la route https://youtu.be/<video-id> atteint sa limite, une autre route avec une limite séparée est disponible sur la route https://youtube.com/embed/<video-id>.
La preuve que les deux routes sont limitées provient d’un utilitaire que j’ai écrit pour modifier le format des intégrations YouTube dans un fil de discussion massif de 10 000 publications comportant 99 % de réponses vidéo YouTube.
À ce stade, Onebox échouait déjà à étendre les liens au format https://youtu.be/<video-id>.
Mon utilitaire, qui convertissait l’URL de la vidéo YouTube au format https://youtube.com/embed/<video-id>, a été exécuté sur les 3 000 premiers messages du fil.
Il a bien fonctionné pour les 1 108 premiers, puis, bien qu’il ait modifié le format pour les ~1 900 messages suivants, ceux-ci n’ont pas été étendus par Onebox.
Pendant ce temps, de nombreuses tâches ont été générées (mon code utilisait post.revise) et toutes ont été traitées sans erreur ni tentative de réessai.
Anecdotiquement, j’ai remarqué que le traitement des tâches semblait s’accélérer considérablement à un certain moment. Je suppose que cela pourrait être dû au fait que le code Onebox recevait rapidement une forme d’erreur de la part de YouTube, mais je n’ai pas chronométré cela et cela pourrait être dû à plusieurs facteurs.
Je serais ravi de fournir des preuves plus détaillées ici, mais je ne suis pas sûr de ce que je peux faire sans instrumenter le gem Onebox.
Je suis un hacker et non un expert Ruby, mais je serais heureux de suivre quelques instructions de haut niveau.
L’exécution de scripts curl courts et répétitifs depuis la ligne de commande du serveur avec le même agent utilisateur peut vous permettre d’isoler un problème de limite de débit.
Je suis d’accord : la solution de contournement fonctionne probablement simplement parce qu’il s’agit d’un compteur distinct.
Voici quelques résultats supplémentaires. Notez qu’il y a de nombreuses hypothèses dans le message ci-dessous, basées sur un manque de connaissances réelles.
Je vais suivre ce message avec mon opinion sur ce qui se passe et ce qui devrait se produire.
Merci pour ta réponse, Robert.
Notez que l’Oneboxing de vidéos via la route /watch échouait (et échoue toujours !) lorsque je l’ai essayé, donc je n’avais pas besoin d’une boucle pour forcer l’échec.
Donc, une hypothèse que j’ai faite est que l’user-agent utilisé par Onebox est Discourse Forum Onebox v2.6.0.beta1, basé sur ce code…
J’ai choisi une vidéo au hasard et j’ai tenté d’utiliser curl pour lire les en-têtes.
Je l’ai fait depuis l’intérieur du conteneur Docker de mon site en production, ce qui a produit la réponse suivante.
Résultat du premier curl utilisant la route /watch?
Je reçois donc un code de réponse 429 “trop de requêtes”, mais sans recevoir d’en-tête retry-after – arrêt immédiat sans négociation.
Quoi qu’il en soit, si c’est ce que voit Onebox, il ignore la réponse ou du moins, je ne sais pas où chercher si cela est enregistré.
Bien que cela puisse être une action légitime pour un seul 429, voir de nombreuses réponses 429 dans une très courte période de temps ne peut pas être ignoré.
Résultat du troisième curl - cette fois en utilisant la route /embed/
Pour être complet, j’ai immédiatement essayé d’obtenir la même vidéo, mais cette fois en utilisant la route /embed/.
Le plugin lazy-yt semble réécrire les URL au format /watch
Je ne sais pas si cela a une quelconque importance, mais… le plugin intégré lazy-yt est-il activé par défaut ? Je l’ai remarqué dans mon installation de développement.
Il semble patcher la méthode to_html de l’Oneboxer YouTube.
Je ne sais pas si c’est important, mais la méthode to_html d’Onebox originale renvoie le format d’URL /embed/…
Alors que le plugin lazy-yt utilise le format d’URL /watch?v=.
Y a-t-il autre chose que je puisse faire pour montrer qu’il y a un problème nécessitant une certaine forme d’attention ? Le prochain message expliquera ce que je pense être la cause racine.
