Erro de restrição no banco de dados do Discourse devido a valores de chave duplicada gerados quando usuários sem conta tentam fazer login via SSO. Isso causa um erro de servidor interno (500) visível através de um proxy externo.
Discussão
Em 28 ou 29 de agosto, atualizei o Discourse para a última versão beta (v2.4.0.beta2), juntamente com todos os plugins instalados. Por volta da mesma época, também atualizei o SeAT e reconfigurei o Discourse para usar um socket UNIX, que o Apache externo pode fazer proxy/reverse proxy. Antes disso, as pessoas conseguiam fazer login via SSO do EVE Online do SeAT, e novas contas de usuário no Discourse eram criadas para elas se ainda não tivessem uma.
Desde então, nenhuma nova conta de usuário foi criada com sucesso. Em vez disso, as três pessoas que tentaram geraram erros do tipo Falha ao criar ou procurar usuário: ERRO: valor de chave duplicada viola a restrição "idx_category_users_user_id_category_id" DETALHE: A chave (user_id, category_id)=(36, 6) já existe.. O category_id é sempre 6, mas o user_id varia entre 33 e 44, repetindo até mesmo números.
Assumindo que category_id se refere a entradas em categories, então 6 parece ser „Cortes de Grama
O que aconteceu aqui foi que alteramos o índice na tabela category_user da seguinte forma:
Você tem um grupo que está ambos definido como “padrão acompanhado” e “padrão rastreado” nas configurações do site?
Verifique: default categories watching, default categories tracking, default categories muted e default categories watching first post.
Isso corrige o problema:
diff --git a/app/models/user.rb b/app/models/user.rb
index c1a94949a6..85b2ca9244 100644
--- a/app/models/user.rb
+++ b/app/models/user.rb
@@ -1390,10 +1390,15 @@ class User < ActiveRecord::Base
return if self.staged?
values = []
+ # allocate set later
+ seen = nil
%w{watching watching_first_post tracking muted}.each do |s|
category_ids = SiteSetting.get("default_categories_#{s}").split("|").map(&:to_i)
category_ids.each do |category_id|
+ seen ||= Set.new
+ next if seen.include?(category_id)
+ seen << category_id
next if category_id == 0
values << "(#{self.id}, #{category_id}, #{CategoryUser.notification_levels[s.to_sym]})"
end
diff --git a/spec/models/user_spec.rb b/spec/models/user_spec.rb
index cc50d88b2e..4075ee6194 100644
--- a/spec/models/user_spec.rb
+++ b/spec/models/user_spec.rb
@@ -1603,8 +1603,12 @@ describe User do
SiteSetting.default_categories_watching = category0.id.to_s
SiteSetting.default_categories_tracking = category1.id.to_s
- SiteSetting.default_categories_muted = category2.id.to_s
+
+ # this is invalid, but we don't validate so ensure nothing breaks
+ SiteSetting.default_categories_muted = "#{category2.id}|#{category0.id}"
+
SiteSetting.default_categories_watching_first_post = category3.id.to_s
+
end
it "has overriden preferences" do
Mas não sou fã dessa correção; as configurações do site deveriam validar que não há sobreposição ao salvar, e deveríamos migrar os dados incorretos.
@daniel Acredito que você tenha introduzido a nova restrição aqui. Talvez seja bom fazer um acompanhamento com uma validação quando as pessoas configurarem a opção nas configurações do site?
Tenho categorias que são rastreadas e categorias que são monitoradas, mas não há sobreposição entre elas. Todas são categorias de nível superior. No entanto, tenho uma sobreposição entre categorias padrão de monitoramento e categorias padrão de monitoramento da primeira postagem. Uma categoria está presente em ambas, e essa categoria coincide com o ID da categoria mencionado no erro de restrição do meu banco de dados. Isso poderia ser parte do problema?
Respondendo a mim mesmo: Remover a categoria de default categories watching first post, deixando-a presente apenas em default categories watching, resolveu o problema; alguém sem conta que anteriormente não conseguia fazer login agora pode fazê-lo.
É muito fácil prevenir duplicatas ao salvar a configuração. Não tenho certeza sobre como corrigir o histórico, porém.
@vinothkannans, você pode garantir que, ao salvar, essas configurações padrão limpem os dados?
Remover duplicatas
Se você estiver salvando “padrão de visualização” para a categoria A … e “padrão de rastreamento” já estiver definido para A, retorne um erro explicando o problema
Minha melhor suposição sobre como isso aconteceu foi:
Criei “Partner Notes” como uma categoria própria e defini-a como “Default Categories Regular”.
Criei “Recruitment Notes” como uma categoria própria e defini-a como “Default Categories Regular”.
Criei “Organizers” como uma categoria própria e defini-a como “Default Categories Regular”.
Alterei as configurações de “Partner Notes” e “Recruitment Notes” para definir sua categoria pai como “Organizers” e (acho que) não fiz nenhuma alteração na configuração “Default Categories Regular”.
Definitivamente apoio a correção desse bug, pois novos usuários não conseguirem se cadastrar é catastrófico e difícil de detectar, já que novos usuários provavelmente desistiriam e não entrariam em contato com ninguém para obter ajuda.
Enquanto isso, talvez a mensagem de erro pudesse incluir algo como: “Se você continuar a ter problemas ao se cadastrar, entre em contato com site email para obter suporte?”.
