Tenho uma atualização com falha e estou tentando descobrir qual mensagem de erro é a causa. Todas as minhas atualizações no último ano ou dois falharam e exigiram muita mexida para serem concluídas.
Notei essas mensagens de dependência de par não atendidas durante cada atualização com falha, mas como não houve muita discussão sobre elas aqui, e eventualmente consegui carregar nosso aplicativo, optei por ignorá-las até agora.
Aqui está um exemplo:
warning " > @glint/environment-ember-loose@1.0.2" has unmet peer dependency "@glimmer/component@^1.1.2".
warning " > @glint/environment-ember-template-imports@1.0.2" has unmet peer dependency "ember-template-imports@^3.0.0".
warning " > @mixer/parallel-prettier@2.0.3" has unmet peer dependency "prettier@^2.0.0".
warning Resolution field "babel-plugin-ember-template-compilation@2.0.0" is incompatible with requested version "babel-plugin-ember-template-compilation@^2.0.1"
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
warning " > babel-plugin-debug-macros@0.4.0-pre1" has unmet peer dependency "@babel/core@^7.0.0".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3@3.0.6" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3-multipart@3.1.3" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/xhr-upload@3.1.1" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" has incorrect peer dependency "@uppy/core@^3.2.1".
Isso é com todos os plugins, exceto o Docker Manager, desativados em meu arquivo app.yml.
A discussão mais semelhante que encontrei sugeriu que o problema de reconstrução poderia ser porque nosso droplet foi criado há muitos anos e é por isso que estamos atrasados em todas essas versões, então a melhor solução é criar um novo droplet e migrar.
Não sei por que suas atualizações não estão funcionando e acredito que as mensagens que você vê não estão relacionadas: são avisos, não erros.
Que tipo de “manipulação”?
Reinstalar o Discourse em um servidor novo é bastante fácil e rápido (dependendo do tamanho do seu fórum, é claro), então você também poderia fazer isso, pode resolver o problema não identificado. Se eu fosse você, com certeza gostaria de saber qual é o problema.
Bem, temos uma tag repetida de alguma forma e isso está impedindo o aplicativo de reconstruir, o que posso corrigir seguindo este guia:
..mas não consigo entrar no aplicativo para corrigi-lo, pois ele não está em execução e não iniciará nem reconstruirá.
Eu estava pensando que isso poderia ser devido a esses erros, e porque nosso Docker e Ubuntu estão um pouco desatualizados.
Acho que vou tentar iniciar um novo Discourse em um novo droplet, instalar o Discourse e depois restaurar nosso último backup nele via linha de comando para que eu possa, espero, corrigir a tag repetida no DB e recarregar o aplicativo.
Eu também gostaria de saber o motivo desses avisos, depois de vê-los agora estou tendo uma falha na compilação também.
111:M 25 Sep 2023 23:13:54.237 # Redis está pronto para sair, tchau tchau...
/usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `readlines': Interrupt
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `block in spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `popen'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:80:in `block in run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/command.rb:8:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:152:in `block (2 levels) in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `block in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:124:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/cli.rb:65:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/bin/pups:9:in `<top (required)>'
from /usr/local/bin/pups:25:in `load'
from /usr/local/bin/pups:25:in `<main>'
Eu estava na compilação estável 3.1.1, editei o arquivo app.yml para incluir o plugin data explorer e agora está falhando. Não faço uma reconstrução completa há algum tempo, usei apenas o console de administração da web para atualizar o discourse e nunca tive problemas até agora. O sistema Ubuntu está atualizado com todos os pacotes.
ATUALIZAÇÃO: Reconstruir pela segunda vez parece ter resolvido o problema, os avisos ainda aparecem, mas a reconstrução foi bem-sucedida. Seria interessante saber por que os avisos estão aparecendo agora e seu impacto (se houver).
Existem muitas maneiras de resolver isso antes que saia do controle. Normalmente, você pode reconstruir ou recarregar um backup anterior e corrigir o duplicado na área de administração. No meu caso, saiu do controle, aqui está um cenário de pior caso para corrigir manualmente o banco de dados, caso isso aconteça com você:
