Score_to_hide_post se vuelve 0 cuando los revisables tienen solo una marca

Error
1

Resumen

score_to_hide_post puede ser forzado a 0 porque el trabajo en segundo plano Jobs::ReviewablePriorities escribe priority_#{priorities[:high]} como 0 cuando la consulta de percentil no devuelve filas. El trabajo se activa cuando reviewable_count >= 15, pero el cálculo del percentil solo incluye los revisables que cumplen HAVING COUNT(*) >= :target_count (donde target_count es típicamente 2). Si la mayoría de los revisables tienen solo una señal, la subconsulta de percentil no devuelve nada → high se convierte en 0 → score_to_hide_post = ((high * ratio) * scale).truncate(2) se evalúa como 0. Esto hace que el umbral de ocultación colapse a cero y produzca un comportamiento de ocultación incorrecto.

De dónde viene esto (código/hechos relevantes)

  • score_to_hide_post se calcula a través de:
score_to_hide_post = ((high.to_f * ratio) * scale).truncate(2)
  • high se lee de la tienda de plugins:
PluginStore.get("reviewables", "priority_#{priorities[:high]}")
  • Esa entrada de la tienda de plugins es escrita por Jobs::ReviewablePriorities (el trabajo del sistema).
    El trabajo se ejecuta cuando:
reviewable_count = Reviewable.approved.where("score > ?", min_priority_threshold).count
return if reviewable_count < self.class.min_reviewables

donde self.class.min_reviewables es 15.

  • El trabajo calcula high usando SQL:
SELECT COALESCE(PERCENTILE_DISC(0.5) WITHIN GROUP (ORDER BY score), 0.0) AS medium,
       COALESCE(PERCENTILE_DISC(0.85) WITHIN GROUP (ORDER BY score), 0.0) AS high
FROM (
  SELECT r.score
  FROM reviewables AS r
  INNER JOIN reviewable_scores AS rs ON rs.reviewable_id = r.id
  WHERE r.score > :min_priority AND r.status = 1
  GROUP BY r.id
  HAVING COUNT(*) >= :target_count
) AS x

con :target_count usualmente 2.

Causa raíz

Hay dos umbrales separados que juntos crean una brecha:

  1. El trabajo se dispara cuando hay al menos min_reviewables (15) revisables por encima de min_priority_threshold — este es un recuento aproximado que ignora el requisito de :target_count.
  2. Pero el cálculo del percentil que produce high solo incluye revisables que tienen COUNT(*) >= :target_count (es decir, al menos 2 reviewable_scores). Si muchos revisables tienen solo una señal, la subconsulta no produce ninguna fila y el percentil devuelve el valor predeterminado 0.0.

Entonces, el trabajo puede ejecutarse (porque hay >= 15 revisables según el recuento aproximado) pero la agregación de percentiles no tiene filas que califiquen (porque ninguna cumple el HAVING), lo que hace que high sea 0 y luego priority_high se escriba como 0. Eso se alimenta a score_to_hide_post y lo colapsa.

Impacto

  • score_to_hide_post se convierte en 0, lo que puede causar incorrectamente que las publicaciones se consideren ocultas o de lo contrario romper la lógica que depende de un umbral de ocultación razonable.
  • Esto ocurre en sitios donde existen muchos revisables pero cada uno tiene solo una señal/revisor, lo cual no es infrecuente en comunidades pequeñas/medianas.

Soluciones sugeridas (opciones)

  1. Asegurar que la consulta de percentil devuelva suficientes filas antes de escribir
  • Después de ejecutar la consulta de percentil, verifique si el valor del percentil es 0 y si la subconsulta devolvió alguna fila.
    Si no se devolvieron filas, no sobrescriba el priority_high existente; en su lugar, omita la escritura, mantenga el valor anterior o recurra a un valor predeterminado configurado.
  • Este es el enfoque más seguro y menos invasivo.
  1. Ajustar el disparador del trabajo para tener en cuenta target_count
  • Modifique la pre-verificación del trabajo para que solo se ejecute cuando el número de revisables que cumplen HAVING COUNT(*) >= :target_count sea al menos min_reviewables.
    En otras palabras, cuente los revisables agrupados por id que satisfacen COUNT(*) >= target_count y solo continúe si ese recuento es >= min_reviewables.
  1. Permitir a los administradores establecer manualmente score_to_hide_post o priority_high
  • Proporcione una opción en la interfaz de administración para ingresar o ajustar directamente score_to_hide_post o priority_high.
  • De esta manera, incluso si la consulta de percentil produce resultados inesperados (por ejemplo, debido a muy pocas muestras), el sistema puede usar un umbral razonable especificado por el administrador, evitando errores causados por cálculos automáticos.