Se controllate la discussione del plugin Custom Wizard di @angus, come utente anonimo, nella vista delle risposte annidate: https://meta.discourse.org/n/-/73345.json?page=0&sort=old
/n/-/73345.json?page=0&sort=old restituisce 20 post radice e ciascuno di essi è un segnaposto eliminato — cooked vuoto, nessun autore, total_descendant_count: 0. Quindi l’intera prima pagina è composta da righe vuote “rimosse”.
La vista piatta degli stessi post non mostra nulla (il post #2 passa direttamente agli argomenti correlati), quindi sono correttamente nascosti lì. La vista annidata li mantiene e li conta per la pagina, il che crea la discrepanza.
Sembra che il caricatore ad albero recuperi i post eliminati intenzionalmente (per mantenere visibile un genitore eliminato quando ha ancora risposte attive sotto di esso), ma sta anche mantenendo i post eliminati che non hanno più risposte visibili. In una discussione come questa, in cui le prime risposte sono state tutte eliminate, alla fine si ottiene una pagina intera di segnaposto vuoti invece di contenuti effettivi.
L’impostazione è sicuramente attiva — l’endpoint ha restituito 200 invece di 404.
Il colpevole sembra essere apply_visibility in NestedReplies::TreeLoader — scope.unscope(where: :deleted_at) recupera ogni post eliminato nell’albero. Ha senso per un genitore eliminato che ha ancora risposte attive sotto di esso, ma sta anche mantenendo i nodi foglia eliminati e i rami completamente eliminati, e questi occupano slot nella finestra ROOTS_PER_PAGE (e contano per has_more_roots).
Per gli utenti non staff, penso che dobbiate rimuovere un post eliminato a meno che non abbia almeno un discendente non eliminato — mantenetelo solo quando il suo total_descendant_count visibile è > 0. NestedViewPostStat esclude già i discendenti eliminati/sussurrati da quel conteggio, quindi non è necessaria una query aggiuntiva.
Dovrebbe essere applicato nei tre punti che costruiscono la pagina in modo da non ottenere pagine corte: root_posts_scope, batch_preload_tree e la parte di riempimento pagina / has_more_roots. Il percorso per lo staff rimane invariato per il recupero.
