Será que é possível que meu bloqueador de anúncios esteja interferindo nisso?
Ao examinar o console do navegador após a atualização, vi duas entradas:
/message-bus/fc3f44b30aea4975be751a4cc8736f76/poll:1 Falha ao carregar o recurso: net::ERR_HTTP2_PROTOCOL_ERROR
docker/upgrade:1 Falha ao carregar o recurso: o servidor respondeu com um status 504 ()
Vejo o mesmo. De fato, seja o que for que o botão ‘Iniciar Atualização’ se torne quando a atualização começa — acho que costumava mudar para algum tipo de botão Cancelar —, notei que ele voltou rapidamente para ‘Iniciar Atualização’ enquanto a atualização ainda estava em andamento e permaneceu assim mesmo após a conclusão bem-sucedida da atualização. Estou usando o Chrome Versão 86.0.4240.80 (Build Oficial) (x86_64) em um Mac.
Isso aconteceu em uma atualização anterior. A atualização atual é da versão 2.6.0.beta3 para a 2.6.0.beta4. Acredito que a atualização imediatamente anterior exigiu uma reconstrução do aplicativo.
Edição: no meu outro fórum, acabei de ver o mesmo e tirei algumas capturas de tela. O botão voltou ao estado anterior enquanto o log ainda mostrava uma das muitas mensagens ‘Aguardando o reinício do Unicorn’ no início. (Eu especulo que a mudança seja baseada no tempo decorrido, e não no progresso da atualização. Edição: 60 segundos entre o clique no botão e a reversão. Enquanto isso, a barra de progresso começou a se mover por volta dos 90 segundos.) Veja abaixo:
Reiniciar a máquina (talvez apenas o contêiner Docker) ou reiniciar o redis deve resolver, acho eu. Não temos etapas de reprodução claras para isso, mas eu também já vi acontecer, então definitivamente ocorre.
É quase todo apenas cosmético, então não é alta prioridade. Se tivéssemos etapas de reprodução claras e consistentes…
Consegui reproduzir isso. O código do cliente não mudou de forma significativa. Parece que o problema é que uma chamada para /admin/docker/upgrade agora está retornando um erro 504 de gateway timeout.
Nosso manipulador de erros então instrui a marcar seu estado como “não atualizando”, o que significa que, quando a notificação do message bus para conclusão chegar, ela não será marcada como finalizada.
Parece-me que a causa raiz aqui é o timeout 504 que não tínhamos visto antes. Suspeito de alguma mudança no proxy ou no Rails aqui. Talvez algo na nossa imagem Docker? @sam, você está ciente de algo ou pode talvez atribuir isso ao DevOps?
Vejo algumas coisas estranhas acontecendo no cliente que estão causando certa surpresa:
Por que estamos fazendo requisições HTTP para o servidor durante a atualização? Parece que estamos fazendo uma requisição para /admin/docker/upgrade no meio da atualização, o que é confuso para mim. Deveríamos apenas aguardar o message bus. Executei isso no Firefox, então tenho depuração limitada.
O message bus não usa long polling, apenas short polling, o que leva a limites de taxa.
“Ir para a próxima atualização” é um pouco confuso; deveríamos apenas dizer “concluído” quando terminarmos de atualizar uma parte, em vez de mudar rapidamente para a outra parte.
@Osama, você pode dedicar algum tempo para depurar/refinar/atualizar o Ember e assim por diante? Acho que a maior parte disso parece ser trabalho no cliente.
Nota para as pessoas sobre este tópico: vamos resolver isso, mas provavelmente levará de 2 a 4 semanas. Como isso vem acontecendo há um mês, acho que podemos esperar um pouco.
Nunca vi isso antes - faz parte de ‘Atualizar Tudo’?
Isso está ótimo para mim, claro. Achei que vi alguém dizer que havia clicado acidentalmente em ‘Iniciar Atualização’ quando ela reapareceu - espero que isso seja inofensivo. Nunca usei ‘Redefinir Atualização’, mas presumo que seja um recurso de segurança caso a atualização fique travada.