# Score\_to\_hide\_post diventa 0 quando i recensibili hanno solo un flag

**URL:** https://meta.discourse.org/t/score-to-hide-post-becomes-0-when-reviewables-each-have-only-one-flag/388088
**Category:** Bug
**Created:** [11 Novembre 2025, 12:33am UTC](https://meta.discourse.org/t/score-to-hide-post-becomes-0-when-reviewables-each-have-only-one-flag/388088 "2025-11-11T00:33:23Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![copymonopoly](https://avatars.discourse-cdn.com/v4/letter/c/4491bb/32.png) [@copymonopoly](https://meta.discourse.org/u/copymonopoly)
#### Post date: [11 Novembre 2025, 12:33am UTC](https://meta.discourse.org/t/score-to-hide-post-becomes-0-when-reviewables-each-have-only-one-flag/388088/1 "2025-11-11T00:33:23Z")

</div>

### 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:

```ruby
score_to_hide_post = ((high.to_f * ratio) * scale).truncate(2)

```

- `high` viene letto dal plugin store:

```ruby
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:

```ruby
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:

```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.