Sim, quando um usuário é excluído, removemos ele de todos os eventos para os quais confirmou presença. Talvez seja esse código que esteja causando isso.
Porque todos os IDs de tópico no erro são tópicos que usam o Events.
Hmm, tenho quase certeza de que esses usuários específicos que estou excluindo não confirmaram presença, mas pode ser que esses sejam os únicos tópicos com confirmação de presença habilitada?
Ah, entendi.
@fzngagan isso está usando .find( inseguro?
topics = Topic.find(topic_ids) if topic_ids
Veja acima a correção que acabei de enviar para o Follow (embora a solução aqui possa precisar ser diferente, já que há vários IDs — usar where?)
Acabei de atualizar, mas ainda recebo o erro 404.
Bart, aguarde o @fzngagan aplicar e confirmar a correção.
Enviei uma correção. Espero que isso resolva o problema. Por favor, verifique e confirme.
Isso resolveu, obrigado!!
Já vi várias vezes posts na fila de revisão com o motivo ‘Novo usuário publicou sua primeira mensagem suspeitosamente rápido’.
Ao verificar mais detalhadamente, notei que esses posts continham uma palavra monitorada, mas isso não era mencionado na fila de revisão.
Como a flag ‘Novo usuário publicou sua primeira mensagem suspeitosamente rápido’ está errada 96% das vezes, e as flaggs de ‘palavras monitoradas’ estão corretas 100% das vezes — ou seja, se um post entra na fila de revisão por causa de uma palavra monitorada, é 100% certo que ele realmente precisa de atenção —, acho que as ‘palavras monitoradas’ deveriam ter precedência sobre ‘novo usuário publicou muito rápido’.
Imagine as seguintes situações:
- Um post entra na fila de revisão por causa de ‘Novo usuário publicou sua primeira mensagem suspeitosamente rápido’. Esse post contém um link de spam invisível que está na lista de ‘palavras monitoradas’. → O post é aprovado, já que ninguém percebe o link invisível (por exemplo, um link atrás de um ‘.’). → Falha!
- Um post entra na fila de revisão por causa de uma palavra monitorada (‘palavras monitoradas’ tendo precedência sobre ‘publicou muito rápido’). Esse post contém um link de spam invisível que está na lista de ‘palavras monitoradas’. → O post é rejeitado e o spammer é banido devido às ‘palavras monitoradas’. → Vitória!
Com certeza, isso é um bug limítrofe. Poderíamos adicionar isso à lista de alguém, @eviltrout? Vejo que o @Roman ainda está designado, talvez?
Corrigido aqui:
Na versão 2.6.0.beta2. Só para avisar, tenho tópicos na fila que parecem ter sido excluídos. Então, acho que o que acontece é algo como:
- A postagem do usuário entra na fila de revisão devido à digitação rápida.
- Eles excluem o tópico (se isso for possível), talvez para reenviá-lo.
Não tenho certeza se isso é intencional ou não. Na fila de revisão, o título está em branco, mas o corpo da postagem está presente e o usuário foi silenciado. Não consigo ver nenhum tópico/postagem no perfil público do usuário.
Sem relação com o acima. Tenho uma sugestão para as opções de filtro. Um recurso que seria excelente, na minha opinião, seria um filtro mais granular para tipos de postagem/tópico. Atualmente, para Tipos, temos:
Postagem sinalizada e Postagem na fila incluem tanto Tópicos quanto Postagens. Acho que seria muito útil se isso fosse alterado para apenas:
Tipo de Revisão:
- Sinalizado
- Na fila
Também poderíamos considerar dividir Sinalizado em Sinalizado pelo Usuário e Sinalizado pelo Sistema.
E então teríamos outro filtro para o tipo de conteúdo.
Tipo de Conteúdo:
- Tópico
- Postagem
- Usuário
Acho que isso seria bastante útil. Por exemplo, poderia ser bastante rápido priorizar a aprovação de Tópicos em vez da aprovação de postagens/respostas. Não há realmente uma maneira de diferenciar entre Tópicos e Postagens com os filtros atuais, exceto por Agrupado por Tópico.
Outra sugestão seria ajustar a interface da fila de revisão para que Tópicos e Postagens sejam um pouco mais fáceis de diferenciar. Atualmente, essas informações são exibidas como um pequeno texto cinza (ou seja, Postagem na fila, Tópico na fila, Postagem sinalizada, Tópico sinalizado). O tamanho do texto é o mesmo das categorias e tags do tópico/postagem.
Para mim, não é imediatamente óbvio se o item é um tópico ou uma postagem/resposta, e eu confundo os dois com frequência.
Algumas ideias:
- Ajustar a seção de Título do Tópico dos itens de postagem para incluir um ícone de resposta, torná-lo menor do que para itens de tópico e talvez incluir o texto RE:
- Aumentar o tamanho do texto/enfase no tipo de item (Tópico/Postagem).
Ao tentar aprovar tópicos e posts, estou recebendo um erro 500. Atualmente estou usando a versão 2.6.0.beta3. Aqui está o log:
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERRO: inteiro fora do intervalo
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
Uma informação potencialmente relevante é que eu tinha o Akismet instalado no passado e o removi (também executei a tarefa rake), conforme detalhado aqui: Feedback on the new Review Queue (2019) - #210 by markersocial
Os itens são dos últimos 60 dias (auto_handle_queued_age: 60). Testei tanto com posts antigos (~2 meses) quanto recentes (nas últimas 3 horas).
Consigo aprovar usuários (Tipo: User) e a opção ‘Excluir Usuário’ em tópicos/posts na fila funciona.
@Roman, isso é super estranho — como estamos obtendo um número inteiro enorme aqui?
O erro é lançado ao tentar criar uma notificação:
Suspeito que provavelmente estamos armazenando
Talvez estejamos armazenando alguns IDs usando o tipo int? O Rails passou a usar BIGINT(8) para chaves primárias na versão 5.1.
@markersorcial, você poderia compartilhar conosco os resultados dessas consultas?
Notification.count
User.count
Topic.count
Obrigado por verificar isso ![]()
Claro, aqui estão os resultados da consulta:
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
Atualização: Ao verificar o Sidekiq, vejo muitas tarefas falhadas com este erro, que parece semelhante:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERRO: inteiro fora do intervalo
Para esses tipos de Tarefa (que notei até agora):
Jobs::PostAlert (mais comum)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
Nenhum desses números deveria estar excedendo o tamanho máximo. Estou me perguntando se algo mais está sobrescrevendo um valor inteiro @Roman.
Então, tem que ser outra coisa. Definitivamente há algo acontecendo e não é específico da fila de revisões.
Esses jobs criam notificações e também estão falhando:
Além disso, se eu tentar fazer algo assim:
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
Obtenho um erro diferente:
ActiveModel::RangeError: 1311344111111 está fora do intervalo para ActiveModel::Type::Integer com limite de 4 bytes
Obtive o mesmo erro ao fazer isso:
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
@markersocial Gostaria de saber se os logs do PostgreSQL poderiam nos fornecer mais informações sobre o erro. Poderia verificar, por favor?
Se você não sabe onde encontrar os logs, consulte:
Nossos moderadores valorizam a capacidade de discutir facilmente as Postagens Sinalizadas entre si e de manter o histórico na Fila de Revisão. Seria possível adicionar a mesma funcionalidade às Postagens na Fila? Utilizamos a configuração approve_post_count para exigir aprovação para as primeiras 5 postagens de novos usuários. Essas primeiras 5 postagens se tornam Postagens na Fila, mas, caso seja necessária uma discussão entre os moderadores, eles precisam iniciar uma mensagem privada, que fica desvinculada da Fila de Revisão e o histórico é perdido.
