Mi farebbe molto piacere ricevere dei consigli su cosa fare in questa situazione, ma ho anche alcune idee su come potrebbe essere gestita meglio.
Cosa potrebbe star succedendo
Una teoria è che il nostro server sia stato identificato da YouTube come potenzialmente coinvolto nel farming di video musicali e che stiamo subendo limitazioni o blocchi.
Siamo un forum davvero insignificante nel Regno Unito con un traffico esiguo, ma abbiamo un paio di thread (in realtà uno diviso in due a causa delle dimensioni) con 10.000 + 2.000 post di video musicali. È una catena musicale in cui il prossimo utente pubblica semplicemente una canzone correlata, spesso in modo tangenziale, al post precedente.
Abbiamo naturalmente altri thread con link a YouTube, ma questo è particolarmente denso di musica (~100%).
Dopo un rifacimento (rebake) nel weekend, ipotizzo che YouTube abbia analizzato l’attività dell’Oneboxer che cercava di recuperare gli header per molti video musicali e il suo algoritmo ci abbia messo sul “banco degli imputati”.
Successivamente, ho riprovato a rifare il baking dei post, il che presumibilmente ha confermato i sospetti di YouTube che da questo indirizzo IP tentiamo solo di scaricare video musicali.
Potrebbe essere correlato a Digital Ocean
Quindi, cercando su Google gli errori 429 su YouTube e ignorando tutti i risultati relativi all’API di YouTube, si arriva a un gruppo di problemi simili che affermano tutti che i loro indirizzi IP sono stati inseriti in liste grigie/nerre o bannati a causa dell’uso di server virtuali; il nome di Digital Ocean è stato menzionato specificamente.
La suggerenza è che YouTube potrebbe “bannare” una serie di indirizzi IP e che altri server legittimi vengono spesso coinvolti come danni collaterali.
Ecco un esempio di tale problema e una potenziale soluzione.
https://support.google.com/youtube/thread/21697789?hl=en
E un altro da uno sviluppatore su medium.com che lavora sull’API embed.ly.
https://support.google.com/youtube/thread/21939228?hl=en
La soluzione suggerita nel primo post era disabilitare IPv6 sul droplet.
Qualcuno sa se questo sembra plausibile o se potrebbe causare problemi?
Ho aspettato per ora di farlo, in modo da poter raccogliere altri dati che potrebbero essere necessari per facilitare la risoluzione.
Cosa dovrebbe accadere?
Innanzitutto, capisco che la reazione qui sia probabilmente che la mia esperienza sia un caso limite e che non siano necessari cambiamenti.
Posso capirlo. Ma se io e @marcozambi abbiamo riscontrato lo stesso problema in un periodo relativamente breve, ciò suggerisce che potrebbe essere qualcosa che altri potrebbero vedere. Forse YouTube è diventato recentemente più severo nel controllo dell’embedding?
Vi chiedo di ricordare che al momento il mio forum è in completo limbo. Ho decine di migliaia di link che non sono stati Oneboxed, ma non so dove si trovino e posso pensare solo a un rifacimento totale per trovarli tutti, il che quasi certamente attirerebbe un’attenzione negativa da parte di YouTube.
Almeno, Onebox non può fallire silenziosamente quando incontra un errore di limite di frequenza (rate-limit). Deve portare la cosa all’attenzione degli amministratori e, dove possibile, fermare il processo che ha innescato il problema del limite di frequenza.
Opzioni per portare questo all’attenzione del proprietario del forum
Non penso che sia facile. Nemmeno un po’.
Vedo Onebox come avente diversi ruoli distintamente diversi:
a) costruisce Onebox in tempo reale mentre i post vengono composti,
b) risponde ai rifacimenti di post vecchi (spesso con link già noti) in background e senza interfaccia (headless)
c) viene richiesto di gestire masse di post di job in background durante una migrazione / rifacimento
Se si verificasse un errore di limite di frequenza durante lo scenario a), l’autore riconoscerebbe che l’Onebox non si è espanso e potrebbe lamentarsi con gli amministratori del forum: potrebbe essere notato. Immagino sia anche possibile catturare il singolo errore durante la composizione e inviare un errore o un messaggio agli amministratori?
Nello scenario b), il fallimento potrebbe avvenire durante l’elaborazione in background del post e quindi dovrebbe essere riprovato o, se il numero di tentativi è stato raggiunto, potrebbe dover fallire e notificare gli amministratori del forum.
Nello scenario c), sarebbe necessario conoscere il contesto più ampio di molti fallimenti che accadono contemporaneamente. Al momento, non credo esista alcun controllo complessivo del processo di rifacimento dei post tale per cui 10.000 errori 429 restituiti da Onebox potrebbero essere riconosciuti come un problema più grande rispetto all’invio di 10.000 messaggi individuali agli amministratori.
In realtà, un fallimento del genere significherebbe che tutte le chiamate a Onebox per l’espansione di video YouTube (potrebbero esserlo anche altri provider) dovrebbero essere messe in pausa finché non saremo più limitati nella frequenza.
Approcci alternativi
Limitare le richieste in uscita
Immagino che l’assioma “prevenire è meglio che curare” potrebbe dettare che un limitatore di frequenza di Discourse possa essere posto davanti alle richieste, in modo che Discourse trattenga le richieste su una base configurata tramite impostazioni.
Questo creerebbe caos con i rifacimenti e le migrazioni.
Onebox Assistant
Forse abbiamo tutti bisogno di relazioni commerciali con organizzazioni che memorizzano e proxyano gli embed, come quella utilizzata da @merefield nel suo plugin Onebox Assistant?
Mettere in whitelist il ‘bot’
Potremmo forse trovare un modo per mettere in whitelist il ‘bot’ di Discourse su YouTube? Probabilmente troppo aperto ad abusi.
API di YouTube
Proprio come Onebox fa con Twitter, forse potremmo usare l’API di YouTube se i limiti di frequenza sono superiori?
