Gostaria muito de receber conselhos sobre o que fazer aqui, mas também tenho algumas ideias sobre como isso poderia ser melhor tratado.
O que pode estar acontecendo
Uma teoria é que nosso servidor pode ter sido identificado pelo YouTube como potencialmente fazendo farming de vídeos de música e, por isso, estamos sendo limitados/bloqueados.
Somos um fórum realmente insignificante no Reino Unido, com tráfego modesto, mas temos alguns tópicos (na verdade, um dividido em dois devido ao tamanho) com 10 mil + 2 mil posts de vídeos de música. É uma corrente musical onde o próximo participante simplesmente posta uma música relacionada, muitas vezes de forma tangencial, ao post anterior.
Temos outros tópicos com links do YouTube, claro, mas este é particularmente denso em música (~100%).
Após uma reprocessamento (rebake) no fim de semana, estou supondo que o YouTube analisou a atividade do Oneboxer tentando capturar cabeçalhos de muitos vídeos de música e seu algoritmo nos colocou no “banco dos culpados”.
Posteriormente, tentei novamente processar os posts, o que presumivelmente confirmou as suspeitas do YouTube de que tudo o que fazemos a partir deste endereço IP é tentar baixar vídeos de música.
Pode estar relacionado à Digital Ocean
Então, pesquisando no Google erros 429 no YouTube e ignorando todos os resultados da API do YouTube, eventualmente cheguei a um grupo de problemas com nomes semelhantes, todos afirmando que seus endereços IP foram listados em cinza/preto/banidos por estarem em servidores virtuais — o nome da Digital Ocean foi especificamente mencionado.
A sugestão é que o YouTube pode “banir” uma série de endereços IP e que outros servidores legítimos são frequentemente arrastados como dano colateral.
Aqui está um desses problemas e uma solução potencial.
https://support.google.com/youtube/thread/21697789?hl=en
e aqui está outro de um desenvolvedor no medium.com que trabalha com a API embed.ly.
https://support.google.com/youtube/thread/21939228?hl=en
A resolução sugerida no primeiro post foi desabilitar o ip6 no droplet.
Alguém sabe se isso parece plausível ou se causaria algum problema?
Ainda não fiz isso por enquanto, para que eu possa coletar quaisquer outros dados que possam ser necessários para ajudar na resolução.
O que deveria acontecer?
Primeiramente, entendo que a reação aqui provavelmente seja a de que minha experiência é um caso isolado e que nenhuma mudança é necessária.
Posso entender isso. Mas se @marcozambi e eu encontramos o mesmo problema em um período relativamente curto, isso sugere que pode ser algo que outros também encontrarão. Talvez o YouTube tenha se tornado recentemente mais rigoroso em sua fiscalização de incorporações?
Peço que lembrem que, no momento, meu fórum está em completo limbo. Tenho dezenas de milhares de links que falharam em ser incorporados (Oneboxed), mas não sei onde estão e só consigo pensar em um reprocessamento total para encontrá-los todos, o que quase certamente atrairá mais atenção negativa do YouTube.
No mínimo, o Onebox não pode falhar silenciosamente ao encontrar um erro de limite de taxa (rate-limit). Ele deve chamar a atenção dos administradores e, quando possível, pausar o processo que desencadeou o problema de limite de taxa.
Opções para chamar a atenção do dono do fórum
Não acho que isso seja fácil. De forma alguma.
Vejo o Onebox desempenhando vários papéis distintos:
a) ele cria Oneboxes em tempo real à medida que os posts são compostos,
b) ele responde a reprocessamentos de posts antigos (com links muitas vezes já conhecidos) em segundo plano e sem interface gráfica (headless),
c) ele é solicitado a lidar com massas de posts de trabalho em segundo plano durante uma migração/reprocessamento.
Se um erro de limite de taxa ocorresse no cenário a), o autor perceberia que o Onebox não foi expandido e poderia reclamar com os administradores do fórum — talvez fosse notado. Acredito também que seja possível capturar o único erro durante a composição e enviar um erro ou mensagem aos administradores.
No cenário b), a falha pode ocorrer durante o processamento em segundo plano do post e, portanto, precisaria ser re tentada ou, se uma contagem de tentativas tivesse sido atingida, poderia ser marcada como falha e os administradores do fórum notificados.
No cenário c), seria necessário conhecer o contexto mais amplo de muitas falhas ocorrendo ao mesmo tempo. No momento, não acredito que exista algum controle abrangente do processo de reprocessamento de posts, de modo que 10.000 erros 429 retornados pelo Onebox pudessem ser reconhecidos como um problema maior do que enviar 10.000 mensagens individuais aos administradores.
Na realidade, uma falha como essa significaria que todas as chamadas ao Onebox para expansão de vídeos do YouTube (podem ser outros provedores também) precisariam ser colocadas em espera até que não estejamos mais limitados por taxa.
Abordagens alternativas
Limitar taxa de solicitações de saída
Acho que o ditado “prevenção é melhor que cura” poderia ditar que um limitador de taxa (rate-limiter) do Discourse fosse colocado na frente das solicitações, para que o Discourse então segurasse as solicitações com base em algumas configurações configuradas.
Isso causaria caos nos reprocessamentos e migrações.
Assistente Onebox
Talvez todos precisemos de relações comerciais com organizações que armazenam em cache e proxy incorporações, como a usada por @merefield em seu plugin Onebox Assistant?
Whitelist do ‘bot’
Seria possível encontrar uma maneira de colocar o ‘bot’ do Discourse na lista branca (whitelist) do YouTube? Provavelmente muito aberto a abusos.
API do YouTube
Assim como o Onebox faz com o Twitter, talvez pudéssemos usar a API do YouTube se os limites de taxa forem maiores?
