Oui, lorsqu’un utilisateur est supprimé, nous le retirons de tous les événements auxquels il a confirmé sa présence. Peut-être que ce code est à l’origine du problème.
3 « J'aime »
Parce que tous les identifiants de sujet dans l’erreur correspondent à des sujets qui utilisent l’application Événements.
Hmm, je suis assez certain que ces utilisateurs spécifiques que je supprime n’ont pas confirmé leur présence, mais il se pourrait que ce soient les seuls sujets ayant l’option de confirmation de présence activée ?
3 « J'aime »
Oh oh, compris.
@fzngagan, cela utilise .find( non sécurisé ?
topics = Topic.find(topic_ids) if topic_ids
Voir ci-dessus la correction que je viens de pousser vers Follow (bien que la solution ici puisse devoir être différente car il y a plusieurs identifiants — utiliser where ?)
3 « J'aime »
Je viens de mettre à jour, mais j’obtiens toujours une erreur 404.
1 « J'aime »
Bart, attends que @fzngagan applique et confirme une correction.
5 « J'aime »
J’ai appliqué un correctif. Il devrait, espérons-le, résoudre le problème. Veuillez vérifier et confirmer.
5 « J'aime »
C’est réglé, merci !!
6 « J'aime »
J’ai remarqué à plusieurs reprises des publications dans la file d’examen avec le motif « Un nouvel utilisateur a publié son premier message suspectement rapidement ». En vérifiant plus en détail, j’ai constaté que ces publications contenaient un mot surveillé, mais cela n’était pas mentionné dans la file d’examen.
Puisque le signalement « Un nouvel utilisateur a publié son premier message suspectement rapidement » est erroné dans 96 % des cas, tandis que les signalements liés aux « mots surveillés » sont corrects à 100 %, c’est-à-dire qu’une publication qui arrive dans la file d’examen à cause d’un mot surveillé nécessite presque toujours une attention particulière, je pense que les « mots surveillés » devraient avoir la priorité sur le motif « nouvel utilisateur a publié trop rapidement ».
Imaginez les situations suivantes :
- Une publication arrive dans la file d’examen en raison du motif « Un nouvel utilisateur a publié son premier message suspectement rapidement ». Cette publication contient un lien spam invisible qui figure dans la liste des « mots surveillés ». → La publication est approuvée, car personne ne remarque le lien invisible (par exemple, un lien caché derrière un « . »). → Échec !
- Une publication arrive dans la file d’examen en raison d’un mot surveillé (les « mots surveillés » ayant la priorité sur « publié trop rapidement »). Cette publication contient un lien spam invisible qui figure dans la liste des « mots surveillés ». → La publication est rejetée et le spammeur est supprimé en raison du mot surveillé → Victoire !
5 « J'aime »
Absolument, c’est un bug à la limite. Pourrions-nous l’ajouter à la liste de quelqu’un @eviltrout ? Je vois que @Roman est toujours assigné, peut-être ?
4 « J'aime »
Corrigé ici :
8 « J'aime »
Sur la version 2.6.0.beta2. Petit avertissement : j’ai des sujets mis en file d’attente qui semblent avoir été supprimés. Je pense que ce qui se passe ressemble à ceci :
- Un message d’un utilisateur est placé dans la file d’examen en raison d’une frappe trop rapide.
- Il supprime son sujet (si cela est possible), peut-être pour le soumettre à nouveau.
Je ne sais pas si c’est intentionnel ou non. Dans la file d’examen, le titre est vide, mais le corps du message est présent et l’utilisateur est mis en sourdine. Je ne vois aucun sujet/message dans le profil public de l’utilisateur.
Sans rapport avec ce qui précède. J’ai une suggestion concernant les options de filtrage. Une fonctionnalité qui serait vraiment géniale, à mon avis, serait un filtre plus granulaire pour les types de messages/sujets. Actuellement, pour les types, nous avons :
Les messages signalés et les messages en file d’attente incluent à la fois des sujets et des messages. Je pense qu’il serait très utile de modifier cela pour avoir uniquement :
Type d’examen :
- Signalé
- En file d’attente
On pourrait également envisager de diviser « Signalé » en « Signalé par l’utilisateur » et « Signalé par le système ».
Ensuite, ajouter un autre filtre pour le type de contenu :
Type de contenu :
- Sujet
- Message
- Utilisateur
Je pense que cela serait très utile. Par exemple, il serait possible de prioriser rapidement l’approbation des sujets par rapport à celle des messages/réponses. Avec les filtres actuels, il n’y a pas vraiment de moyen de distinguer les sujets des messages, sauf via le regroupement par sujet.
Une autre suggestion serait d’ajuster l’interface de la file d’examen afin que les sujets et les messages soient un peu plus faciles à distinguer. Actuellement, cette information est affichée sous forme de petit texte gris (par exemple : Message en file d’attente, Sujet en file d’attente, Message signalé, Sujet signalé). La taille du texte est la même que celle des catégories et des balises du sujet/message.
Pour moi, il n’est pas immédiatement évident de savoir si l’élément est un sujet ou un message/réponse, et je confonds souvent les deux.
Quelques idées :
- Ajuster la section du titre du sujet des éléments de message pour y inclure une icône de réponse, la rendre plus petite que pour les éléments de sujet et peut-être ajouter le texte RE :
- Augmenter la taille du texte/la mise en évidence du type d’élément (Sujet/Message).
2 « J'aime »
Lorsque j’essaie d’approuver des sujets et des messages, je reçois une erreur 500. J’utilise actuellement la version 2.6.0.beta3. Voici le journal :
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
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'
Une information potentiellement pertinente est que j’avais installé Akismet par le passé et que je l’ai désinstallé (en exécutant également la tâche rake), comme détaillé ici : Feedback on the new Review Queue (2019) - #210 by markersocial
Les éléments concernent les 60 derniers jours (auto_handle_queued_age: 60). J’ai testé à la fois avec d’anciens messages (~2 mois) et récents (moins de 3 heures).
Je peux approuver des utilisateurs (Type: User) et l’option « Supprimer l’utilisateur » sur les sujets/messages en file d’attente fonctionne.
2 « J'aime »
@Roman, c’est vraiment bizarre - comment on se retrouve avec un entier géant ici ?
6 « J'aime »
L’erreur est levée lors de la tentative de création d’une notification :
Je soupçonne que nous stockons peut-être
Peut-être stockons-nous certains identifiants en utilisant le type int ? Rails a commencé à utiliser BIGINT(8) pour les clés primaires dans la version 5.1.
@markersorcial Pourriez-vous s’il vous plaît nous communiquer les résultats de ces requêtes ?
Notification.count
User.count
Topic.count
4 « J'aime »
Merci d’avoir examiné cela 
Bien sûr, voici les résultats de la requête :
Notification.count : 1 506 604
User.count : 238 083
Topic.count : 936 067
3 « J'aime »
Mise à jour : En consultant Sidekiq, je constate de nombreuses tâches échouées avec cette erreur qui semble similaire :
Jobs::HandledExceptionWrapper : Wrapped ActiveRecord::RangeError : PG::NumericValueOutOfRange : ERROR: integer out of range
Pour ces types de tâches (que j’ai remarqués jusqu’à présent) :
Jobs::PostAlert (le plus courant)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
1 « J'aime »
Aucun de ces chiffres ne devrait dépasser la taille maximale. Je me demande si autre chose n’écrase pas une valeur entière @Roman.
3 « J'aime »
Il doit donc s’agir de quelque chose d’autre. Il se passe clairement quelque chose, et ce n’est pas spécifique à la file d’attente de modération.
Ces tâches génèrent des notifications et échouent également :
De plus, si j’essaie de faire quelque chose comme ceci :
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
j’obtiens une erreur différente :
ActiveModel::RangeError: 1311344111111 est hors de la plage autorisée pour ActiveModel::Type::Integer avec une limite de 4 octets
J’ai obtenu la même erreur en faisant ceci :
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
6 « J'aime »
@markersocial Je me demande si les journaux PostgreSQL pourraient nous aider à obtenir plus d’informations sur l’erreur. Pourriez-vous vérifier ?
Si vous ne savez pas où trouver les journaux, consultez :
5 « J'aime »
Nos modérateurs apprécient la possibilité de discuter facilement des publications signalées entre eux et de conserver l’historique dans la file d’examen. Serait-il possible d’ajouter la même fonctionnalité aux publications en attente ? Nous utilisons le paramètre approve_post_count pour exiger l’approbation des cinq premières publications d’un nouvel utilisateur. Ces cinq premières publications deviennent des publications en attente, mais si une discussion entre modérateurs est nécessaire, ils doivent lancer un message privé qui est détaché de la file d’examen et l’historique est perdu.
3 « J'aime »