Score_to_hide_post diventa 0 quando i recensibili hanno solo un flag

Bug
1

Riepilogo

score_to_hide_post può essere portato a 0 perché il job in background Jobs::ReviewablePriorities scrive priority_#{priorities[:high]} come 0 quando la query percentile non restituisce righe. Il job viene attivato quando reviewable_count >= 15, ma il calcolo del percentile include solo gli elementi revisionabili che soddisfano HAVING COUNT(*) >= :target_count (dove target_count è tipicamente 2). Se la maggior parte degli elementi revisionabili ha solo un flag, la sottoquery del percentile non restituisce nulla → high diventa 0 → score_to_hide_post = ((high * ratio) * scale).truncate(2) viene valutato a 0. Ciò causa il collasso della soglia di nascondimento a zero e produce un comportamento di nascondimento errato.

Origine (codice / fatti pertinenti)

  • score_to_hide_post è calcolato tramite:
score_to_hide_post = ((high.to_f * ratio) * scale).truncate(2)
  • high viene letto dal plugin store:
PluginStore.get("reviewables", "priority_#{priorities[:high]}")
  • Questa voce del plugin store viene scritta da Jobs::ReviewablePriorities (il job di sistema).
    Il job viene eseguito quando:
reviewable_count = Reviewable.approved.where("score > ?", min_priority_threshold).count
return if reviewable_count < self.class.min_reviewables

dove self.class.min_reviewables è 15.

  • Il job calcola 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 solitamente 2.

Causa principale

Ci sono due soglie separate che insieme creano una lacuna:

  1. Il job viene attivato quando ci sono almeno min_reviewables (15) elementi revisionabili al di sopra di min_priority_threshold — questo è un conteggio approssimativo che ignora il requisito di :target_count.
  2. Ma il calcolo del percentile che produce high include solo gli elementi revisionabili che hanno COUNT(*) >= :target_count (cioè, almeno 2 punteggi di revisione). Se molti elementi revisionabili hanno solo un flag, la sottoquery non produce righe e il percentile restituisce il valore predefinito 0.0.

Quindi il job può essere eseguito (perché ci sono >= 15 elementi revisionabili secondo il conteggio approssimativo) ma l’aggregazione del percentile non ha righe qualificate (perché nessuna soddisfa HAVING), causando high a 0 e quindi priority_high scritto come 0. Questo si ripercuote su score_to_hide_post e lo fa collassare.

Impatto

  • score_to_hide_post diventa 0, il che può causare erroneamente la considerazione di post come nascosti o altrimenti interrompere la logica che dipende da una ragionevole soglia di nascondimento.
  • Ciò si verifica su siti in cui esistono molti elementi revisionabili ma ognuno ha solo un singolo flag/revisore, il che non è raro nelle comunità piccole/medie.

Correzioni suggerite (opzioni)

  1. Assicurarsi che la query percentile restituisca abbastanza righe prima di scrivere
  • Dopo aver eseguito la query percentile, verificare se il valore del percentile è 0 e se la sottoquery ha restituito righe.
    Se non sono state restituite righe, non sovrascrivere il priority_high esistente; invece, saltare la scrittura, mantenere il valore precedente o utilizzare un valore predefinito configurato.
  • Questo è l’approccio più sicuro e meno invasivo.
  1. Regolare l’attivazione del job per tenere conto di target_count
  • Modificare il pre-controllo del job in modo che venga eseguito solo quando il numero di elementi revisionabili che soddisfano HAVING COUNT(*) >= :target_count è almeno min_reviewables.
    In altre parole, contare gli elementi revisionabili raggruppati per id che soddisfano COUNT(*) >= target_count e procedere solo se quel conteggio è >= min_reviewables.
  1. Consentire agli amministratori di impostare manualmente score_to_hide_post o priority_high
  • Fornire un’opzione nell’interfaccia di amministrazione per inserire o regolare direttamente score_to_hide_post o priority_high.
  • In questo modo, anche se la query percentile produce risultati inaspettati (ad esempio, a causa di campioni troppo pochi), il sistema può utilizzare una soglia ragionevole specificata dall’amministratore, prevenendo errori causati da calcoli automatici.