Da alcuni giorni (direi subito dopo l’aggiornamento a Discourse 2.5 beta 5 - e continua sulla beta 6 - ma potrebbe essere una coincidenza) l’incorporamento dei video di YouTube funziona in modo intermittente. Dopo alcune ore di malfunzionamento, riprende a funzionare correttamente.
Da ieri, ha smesso di funzionare completamente.
Non vedo errori specifici sospetti nei log del forum.
Potrebbe essere un problema di timeout? Esiste un modo per indagare specificamente su questo?
Ho notato qualcosa di strano esaminando il traffico generato dalla richiesta di rigenerare un post contenente un link a YouTube.
La richiesta fallisce con l’errore 404.
Un altro piccolo dettaglio.
Sto eseguendo Discourse 2.5.0.beta6 aggiornato al commit 2d880b42a3 (ricompilato poco prima di inviare questo post).
Quando creo un nuovo post con un link a YouTube, dalla console di Google Chrome noto un errore aggiuntivo subito prima del 404 per la richiesta GET a onebox, relativo a un errore di registrazione del Service Worker.
Voglio sottolineare che qualsiasi onebox funziona, tranne YouTube.
se ripeto la semplice chiamata GET (passando intestazioni e altro come previsto) a /onebox?url=… ottengo semplicemente l’errore HTML 404
se ripeto, sul server, la richiesta che onebox esegue, copiandola dal codice Ruby di youtube_onebox.rb, ovvero curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' per uno dei video non incorporati, sembra funzionare perfettamente.
La chiamata restituisce effettivamente: {"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#
che contiene tutto ciò di cui onebox ha bisogno per l’incorporamento.
@Falco, scusami davvero per il disturbo, ma la mancanza di oneboxing per YouTube sta davvero compromettendo l’esperienza utente del nostro forum.
Ieri ho provato diverse cose, come cercare di leggere il codice sorgente (per capire a quale stadio e con quale condizione potrebbe essere restituito un 404 da onebox) fino a clonare il forum di produzione attuale su un nuovo droplet Digital Ocean separato.
Leggere il codice non è stato molto utile, principalmente a causa della mia mancanza di conoscenze reali della piattaforma.
Una domanda rimane aperta: il processo di oneboxing registra qualcosa da qualche parte? Sarebbe così utile capire l’errore che porta onebox a desistere e restituire un 404.
Il droplet clonato era un tentativo per verificare se l’indirizzo IP del server di produzione fosse stato bannato da YouTube e, allo stesso tempo, se ci fosse qualcosa legato al nome di dominio che utilizziamo.
Bene, anche se l’indirizzo IP e il nome di dominio erano diversi, l’oneboxing di YouTube non funzionava.
Spero davvero che qualcuno possa suggerirmi almeno un modo per tracciare cosa fa l’oneboxing.
Ho individuato la causa principale: YouTube ha bloccato il nostro IP, ma non è chiaro il motivo, poiché al momento dell’incidente non stavamo eseguendo alcuna massiccia ricottura o operazioni simili.
Domanda per @Falco o @codinghorror: l’installazione della versione 2.5.0beta 5 o 6 ha attivato qualche ricottura, che avrebbe superato il limite delle richieste?
Grazie a tutti per le risposte.
Tuttavia, non mi è ancora chiaro perché, se imito la richiesta che effettua il motore onebox (o almeno mi aspetto che sia così. È @Falco?), ottengo una risposta JSON con una risposta corretta e non un errore 429.
C’è un’altra richiesta effettuata da Onebox che restituisce un 429, prima di eseguire la richiesta mostrata nello screenshot, ovvero curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik'?
È ovvio che queste richieste siano state effettuate dallo stesso server su cui è in esecuzione Discourse (quindi stessa IP in uscita).
Un risultato interessante dopo un weekend di risoluzione dei problemi.
Forse è qualcosa su cui vorresti dare un’occhiata, @Falco o @codinghorror?
Al momento, leggendo il codice sorgente di youtube_onebox.rb, vedo che supporta 3 URL da cui viene estratto l’ID del video:
http://youtu.be/<videoid>
https://www.youtube.com/embed/<videoid>
https://www.youtube.com/watch?v=<videoid>
Ogni tentativo di generare un onebox per video i cui link sono nei formati 1 e 3 fallisce, con onebox che restituisce un errore 404 (penso che sia legato al fatto che il nostro IP sia stato bloccato).
Quando provo a incorporare link con il formato 2, funziona!
Mi chiedo se e come questo possa essere correlato al fatto spiegato in questo post.
Una comprensione (e un registro delle attività) del funzionamento interno di onebox (cioè quali chiamate esatte vengono effettuate a YouTube) sarebbe estremamente utile…
Sono tornato per chiudere questa discussione.
Ieri YouTube ha rimosso il nostro blocco e siamo di nuovo operativi.
Ci sono alcuni punti che, a mio avviso, sarebbe interessante comprendere comunque:
Onebox potrebbe registrare i dettagli in caso di fallimento del oneboxing? Sarebbe molto utile capire esattamente perché il oneboxing fallisce.
Dato che l’unico elemento necessario per il oneboxing dei video YouTube è l’ID del video, non sarebbe una buona idea provare a estrarre i dati da ciascuno dei 3 tipi di URL prima di restituire un 404 (come detto sopra, l’URL /embed/ non ha mai smesso di funzionare in qualche modo, anche durante il blocco).
Grazie a tutti quelli che hanno risposto alle mie domande dettate dal panico!
ASSOLUTAMENTE!!! (è un’ottima idea che ho già menzionato in precedenza)
Immagino che una delle sfide qui sia che, se la pagina di destinazione restituisce una pagina senza tag og, Onebox non saprà che ciò è dovuto a qualche reindirizzamento. Tuttavia, questo potrebbe essere registrato (“ONEBOX: nessun tag og trovato”) e tutti gli errori che portano a onebox vuoti dovrebbero essere sicuramente registrati.
tl;dr Vorrei aggiungere che stiamo riscontrando quello che sembra essere lo stesso problema. Se si tratta di un problema di limite di richieste dovuto a qualche modifica recente, penso che altri utenti inizieranno a sperimentarlo durante la migrazione, la ricottura dei post o forse semplicemente a causa di un forum molto attivo. Il fatto che i onebox sembrino fallire silenziosamente significa che questi problemi non sono visibili finché gli utenti non iniziano a lamentarsi della mancanza dei onebox di YouTube.
Contesto
Siamo alla versione 2.6.0.beta 1
Gli utenti ricevevano messaggi relativi a contenuti non sicuri. Dopo un’indagine, Chrome sembrava lamentarsi delle immagini collegate da siti HTTP. Ho quindi configurato Discourse per scaricare tutte le immagini e i media e servirli tramite HTTPS.
Una volta modificata l’impostazione, è stato necessario procedere con una ricottura dei post storici. Da allora, una grande parte dei video YouTube che in precedenza erano stati convertiti in onebox sono tornati a essere semplici URL collegati.
Abbiamo un thread di 10.000 post composto esclusivamente da risposte con video YouTube, e tutti i post contengono URL e non onebox.
Durante la ricottura, tutti i lavori in coda sono stati elaborati in modo organico, quindi non si tratta di lavori bloccati in una coda di lavori eliminati.
Non ho visto gli stessi messaggi di errore descritti da @marcozambi, ma credo che stiamo superando un limite di richieste.
Cosa ho provato?
A sostegno della teoria del limite di richieste, un piccolo frammento di codice che ho scritto per ricotturare i post ha funzionato (ha creato i onebox) per i primi 80+ video YouTube in un thread, per poi fallire nella conversione dei video rimanenti.
A quel punto, anche modificando il post, apportando una piccola correzione e salvandolo di nuovo, non è stato possibile forzare l’espansione dell’URL in un onebox. Nello stesso momento, tutte le code erano vuote o contenevano lavori minori elaborati istantaneamente, come mi aspettavo.
I tentativi di rieseguire quel codice per un periodo di 30 minuti non sono riusciti a forzare la creazione dei onebox per i link. Non credo che 80 sia un numero magico; è semplicemente quello che era disponibile nel nostro quota.
@marcozambi ha menzionato che il formato del link YouTube /embed/ funzionava quando gli altri fallivano, quindi ho modificato il codice per utilizzare una ricerca e sostituzione con espressioni regolari sui link YouTube per convertirli nel formato /embed/.
Il codice ha funzionato.
Rieseguendo il codice per ricotturare nuovamente i post, non è stato possibile ottenere le rappresentazioni onebox.
Il mio piano è sperimentare con un’attività che converta tutti i link YouTube nel grande thread nel formato YouTube /embed/. Se ciò fallisce o superiamo un limite di richieste più alto, allora darò un’occhiata a Onebox Assistant di @merefield.
OK, c’è sicuramente qualcosa di strano in corso e sembra essere legato al limite di richieste.
Non sono sicuro se stiamo venendo limitati perché ho eseguito una massiccia rigenerazione e siamo finiti nella “penitenza”, o se stiamo superando limiti che altri vedranno.
Sembra che il Oneboxing dei video YouTube abbia un limite e, una volta raggiunto, il Oneboxing fallisce in modo silenzioso.
Credo che questo debba essere modificato, per ragioni che spero siano ovvie, ma in particolare per chiunque esegua una migrazione o una rigenerazione senza sapere che molti Onebox non espansi o precedentemente espansi sono ora diventati semplici URL.
@marcozambi ha menzionato sopra che il formato URL di YouTube che include /embed/ prima dell’ID del video funziona quando gli altri formati falliscono (presumibilmente a causa di un problema di limite di richieste).
Ecco un video che illustra bene questo fenomeno.
Quando è stato registrato questo screencast, non c’erano processi che intasavano le code e il forum stava altrimenti funzionando bene.
Prima di questo video, i link di YouTube avevano già iniziato a non essere espansi dal OneBox.
Ciò che vedrete è la finestra di composizione in cui il Onebox non riesce a espandere un link YouTube nel formato https://youtu.be/<video-id>.
Poi cambio il formato in https://youtube.com/embed/<video-id> e il Onebox lo espande.
Provo di nuovo con il formato originale e fallisce.
Durante la registrazione di questo video, ho monitorato la console del browser e le schede di rete. Riconosco che il problema è sicuramente tra il nostro server e YouTube piuttosto che tra il mio browser e il nostro server, ma le includo di seguito nel caso fossero utili.
(scuse per la natura zoom-out dell’immagine - spero siano visibili quando ingrandite)
Non sono convinto che il formato di link /embed/ sia una panacea in questo caso.
Penso che sembri essere un percorso con limiti di velocità separati, in modo che quando il percorso https://youtu.be/<video-id> raggiunge un limite, esista un altro percorso con un limite separato sul percorso https://youtube.com/embed/<video-id>.
L’evidenza del fatto che entrambi i percorsi siano limitati proviene da un’utilità che ho scritto per cambiare il formato degli embed di YouTube in un thread mostruoso di 10K post con il 99% di risposte video YouTube.
A questo punto, Onebox stava già fallendo nell’espandere i link formattati https://youtu.be/<video-id>.
La mia utilità, che ha cambiato l’URL del video YouTube nel formato https://youtube.com/embed/<video-id>, è stata eseguita sui primi 3000 post del thread.
Ha funzionato bene per i primi 1108 e poi, mentre cambiava il formato per i successivi ~1900 post, questi non sono stati espansi da Onebox.
Durante questo periodo, sono stati generati molti job (il mio codice usava post.revise) e tutti sono stati elaborati senza errori o tentativi di ripetizione.
Aneddoticamente, ho notato che l’elaborazione dei job sembrava accelerare drammaticamente a una certa fase. Immagino che questo potrebbe essere dovuto al fatto che il codice Onebox stava ricevendo rapidamente qualche tipo di errore da YouTube, ma non l’ho misurato e potrebbe essere stato per una serie di motivi.
Sarei felice di fornire ulteriori prove dettagliate qui, ma non sono sicuro di cosa possa fare senza strumentare il gem Onebox.
Sono un hacker e non un esperto di Ruby, ma sarei lieto di seguire alcune istruzioni di alto livello.
Eseguire alcuni script curl brevi e ripetitivi dalla riga di comando del server con lo stesso user agent potrebbe permetterti di isolare un problema di limitazione della frequenza.
Sono d’accordo che la soluzione alternativa funzioni probabilmente solo perché si tratta di un conteggio separato.
Ecco alcuni risultati aggiuntivi. Nota che ci sono molte ipotesi nel post qui sotto, basate su una mancanza di conoscenze reali.
Farò seguito a questo post con la mia opinione su ciò che sta succedendo e su cosa dovrebbe accadere.
Grazie per la risposta, Robert.
Nota che l’Oneboxing dei video tramite la rotta /watch falliva (e fallisce ancora!) quando ho provato, quindi non ho avuto bisogno di un ciclo per forzare il fallimento.
Quindi un’ipotesi che ho fatto è che lo user-agent utilizzato da Onebox sia Discourse Forum Onebox v2.6.0.beta1, basandomi su questo codice…
Ho scelto un video a caso e ho provato a usare curl per leggere le intestazioni.
L’ho fatto all’interno del contenitore Docker del mio sito in produzione, ottenendo la seguente risposta.
Quindi sono stato reindirizzato con una risposta 303 all’URL presente nell’intestazione location, ovvero https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop.
Questo ha semplicemente avuto l’effetto di aggiungere &app=desktop all’URL.
Risultato del secondo curl all’URL reindirizzato - ancora sulla rotta /watch?
Quindi ricevo un codice di risposta 429 “troppe richieste”, ma senza ricevere un’intestazione retry-after: cessate e desistete senza negoziare.
In ogni caso, se è questo che Onebox sta vedendo, sta ignorando la risposta o almeno non so dove cercare se viene registrata.
Anche se questo potrebbe essere un comportamento legittimo per un singolo 429, vedere molte risposte 429 in un periodo di tempo molto breve non può essere ignorato.
Risultato del terzo curl - questa volta usando la rotta /embed/
Per completezza, ho immediatamente provato a ottenere lo stesso video, ma questa volta usando la rotta /embed/.
Il plugin lazy-yt sembra riscrivere gli URL nel formato /watch
Non sono sicuro che abbia alcuna rilevanza, ma… il plugin embedded lazy-yt è abilitato per impostazione predefinita? L’ho notato nella mia installazione di sviluppo.
Sembra fare monkey patching del metodo to_html dell’Oneboxer di YouTube.
Non so se sia significativo, ma il metodo to_html dell’Onebox originale restituisce il formato URL /embed/…
Mentre il plugin lazy-yt utilizza il formato URL /watch?v=.
C’è qualcos’altro che posso fare per dimostrare che c’è un problema che richiede qualche forma di intervento? Nel prossimo post spiegherò quale ritengo sia la causa principale.
