Sí, cuando se elimina un usuario, lo eliminamos de cualquier evento al que haya confirmado asistencia. Quizás ese código esté causando esto.
3 Me gusta
Porque todos los IDs de tema en el error son temas que utilizan Events.
Hmm, estoy bastante seguro de que estos usuarios específicos que estoy eliminando no han confirmado asistencia, pero podría ser que estos sean los únicos temas con confirmación de asistencia habilitada.
3 Me gusta
Oh, entiendo.
@fzngagan ¿esto está usando .find( inseguro?
topics = Topic.find(topic_ids) if topic_ids
Mira la solución que acabo de subir a Follow (aunque la solución aquí podría necesitar ser diferente, ya que hay múltiples IDs; ¿usar where?)
3 Me gusta
Acabo de actualizar pero sigo recibiendo el error 404.
1 me gusta
Bart, espera a que @fzngagan aplique y confirme una solución.
5 Me gusta
He enviado una corrección. Ojalá resuelva el problema. Por favor, revisa y confirma.
5 Me gusta
¡Eso lo solucionó, gracias!!
6 Me gusta
He visto en varias ocasiones publicaciones en la cola de revisión con el motivo “Un usuario nuevo escribió su primera publicación sospechosamente rápido”.
Al verificar más a fondo, noté que esas publicaciones contenían una palabra vigilada, pero esto no se mencionaba en la cola de revisión.
Dado que la señalización “Un usuario nuevo escribió su primera publicación sospechosamente rápido” es incorrecta el 96 % de las veces, mientras que las señalizaciones por “palabras vigiladas” son correctas el 100 % de las veces (es decir, si una publicación llega a la cola de revisión por una palabra vigilada, es 100 % seguro que realmente necesita atención), considero que las “palabras vigiladas” deberían tener prioridad sobre “usuario nuevo escribió demasiado rápido”.
Imaginen las siguientes situaciones:
- Una publicación llega a la cola de revisión por “Un usuario nuevo escribió su primera publicación sospechosamente rápido”. Esta publicación contiene un enlace de spam invisible que está en la lista de “palabras vigiladas”. → La publicación se aprueba, ya que nadie nota el enlace invisible (por ejemplo, un enlace oculto detrás de un “.”). → ¡Fallo!
- Una publicación llega a la cola de revisión por una palabra vigilada (las “palabras vigiladas” tienen prioridad sobre “escrito demasiado rápido”). Esta publicación contiene un enlace de spam invisible que está en la lista de “palabras vigiladas”. → La publicación se rechaza y el spammer es eliminado por “palabras vigiladas”. → ¡Victoria!
5 Me gusta
Absolutamente, esto es un error limítrofe. ¿Podríamos añadir esto a la lista de alguien @eviltrout? Veo que @Roman aún está asignado, ¿quizás?
4 Me gusta
Corregido aquí:
8 Me gusta
En la versión 2.6.0.beta2. Solo para avisar: tengo temas en cola que parecen haber sido eliminados. Creo que esto ocurre de la siguiente manera:
- La publicación de un usuario se coloca en la cola de revisión debido a que escribe muy rápido.
- Elimina su tema (si eso es posible), quizás para volver a enviarlo.
No estoy seguro de si esto es intencional o no. En la cola de revisión, el título aparece en blanco, pero el cuerpo del mensaje está presente y el usuario ha sido silenciado. No puedo ver ningún tema/publicación en el perfil público del usuario.
Sin relación con lo anterior. Tengo una sugerencia para las opciones de filtrado. Una función que, en mi opinión, sería muy útil, sería un filtro más granular para los tipos de publicaciones/temas. Actualmente, para los Tipos tenemos:
«Publicación señalada» y «Publicación en cola» incluyen tanto temas como publicaciones. Creo que sería muy útil si esto se cambiara a simplemente:
Tipo de revisión:
- Señalado
- En cola
También se podría considerar dividir «Señalado» en «Señalado por usuario» y «Señalado por el sistema».
Luego, incluir otro filtro para el tipo de contenido:
Tipo de contenido:
- Tema
- Publicación
- Usuario
Creo que esto sería muy útil. Por ejemplo, podría ser bastante rápido priorizar la aprobación de temas sobre la de publicaciones o respuestas. Con los filtros actuales, no hay realmente una manera de diferenciar entre temas y publicaciones, aparte de «Agrupado por tema».
Otra sugerencia sería ajustar la interfaz de la cola de revisión para que sea un poco más fácil diferenciar entre temas y publicaciones. Actualmente, esta información se muestra como un texto gris pequeño (es decir, Publicación en cola, Tema en cola, Publicación señalada, Tema señalado). El tamaño del texto es el mismo que el de las categorías y etiquetas del tema/publicación.
Para mí, no es inmediatamente obvio si el elemento es un tema o una publicación/respuesta, y a menudo los confundo.
Algunas ideas:
- Ajustar la sección del título del tema en los elementos de publicación para incluir un icono de respuesta, hacerlo más pequeño que para los elementos de tema y quizás incluir el texto RE:
- Aumentar el tamaño del texto/énfasis en el tipo de elemento (Tema/Publicación).
2 Me gusta
Al intentar aprobar temas y publicaciones, obtengo un error 500. Actualmente estoy usando la versión 2.6.0.beta3. Aquí está el registro:
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: entero fuera de rango
)
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'
Alguna información potencialmente relevante es que anteriormente tenía Akismet instalado y lo eliminé (también ejecuté la tarea rake), como se detalla aquí: Feedback on the new Review Queue (2019) - #210 by markersocial
Los elementos son de los últimos 60 días (auto_handle_queued_age: 60). He probado tanto con publicaciones antiguas (~2 meses) como recientes (en las últimas 3 horas).
Puedo aprobar usuarios (Tipo: Usuario) y la opción ‘Eliminar usuario’ en temas/publicaciones en cola funciona.
2 Me gusta
@Roman, esto es súper extraño: ¿cómo estamos obteniendo un entero tan grande aquí?
6 Me gusta
El error se lanza al intentar crear una notificación:
Sospecho que probablemente estamos almacenando
¿Quizás estamos almacenando algunos IDs usando el tipo int? Rails comenzó a usar BIGINT(8) para las claves primarias en la versión 5.1.
@markersorcial ¿Podrías compartir con nosotros los resultados de estas consultas?
Notification.count
User.count
Topic.count
4 Me gusta
Gracias por investigar esto 
Claro, aquí están los resultados de la consulta:
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
3 Me gusta
Actualización: Al revisar Sidekiq, veo muchas tareas fallidas con este error que parece similar:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: entero fuera de rango
Para estos tipos de Tarea (que he notado hasta ahora):
Jobs::PostAlert (más común)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
1 me gusta
Ninguno de esos números debería superar el tamaño máximo. Me pregunto si algo más está sobrescribiendo un valor entero, @Roman.
3 Me gusta
Entonces tiene que ser otra cosa. Definitivamente está ocurriendo algo y no es específico de la cola de revisiones.
Estos trabajos crean notificaciones y también están fallando:
Además, si intento hacer algo como esto:
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
Obtengo un error diferente:
ActiveModel::RangeError: 1311344111111 está fuera de rango para ActiveModel::Type::Integer con un límite de 4 bytes
Obtuve el mismo error al hacer esto:
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: entero fuera de rango
6 Me gusta
@markersocial Me pregunto si los registros de PostgreSQL podrían ayudarnos a obtener más información sobre el error. ¿Podrías revisarlos, por favor?
Si no sabes dónde encontrar los registros, consulta:
5 Me gusta
Nuestros moderadores valoran la posibilidad de discutir fácilmente las Publicaciones Marcadas entre ellos y mantener el historial en la Cola de Revisión. ¿Sería posible añadir la misma capacidad a las Publicaciones en Cola? Utilizamos la configuración approve_post_count para requerir aprobación para los primeros 5 posts de un nuevo usuario. Esos primeros 5 posts se convierten en Publicaciones en Cola, pero si se requiere discusión entre moderadores, deben iniciar un mensaje privado que queda desconectado de la Cola de Revisión y se pierde el historial.
3 Me gusta