La vue des réponses imbriquées (/n/) remplit les pages avec des espaces réservés pour les messages supprimés, que la vue plate omet

Si vous consultez la discussion du plugin Custom Wizard d’@angus en tant qu’utilisateur anonyme, avec l’affichage des réponses imbriquées : https://meta.discourse.org/n/-/73345.json?page=0&sort=old

/n/-/73345.json?page=0&sort=old renvoie 20 messages racine, et chacun d’eux est un espace réservé supprimé — cooked vide, aucun auteur, total_descendant_count: 0. Ainsi, toute la première page est constituée de lignes « supprimées » vides.

L’affichage linéaire des mêmes messages ne montre rien du tout (le message #2 passe directement aux sujets connexes), donc ils sont correctement masqués dans ce cas. L’affichage imbriqué, lui, les conserve et les compte pour la pagination, ce qui crée cette incohérence.

Il semble que le chargeur d’arbres récupère intentionnellement les messages supprimés (afin de garder visible un message parent supprimé lorsqu’il contient encore des réponses actives en dessous), mais il conserve également les messages supprimés qui n’ont plus de réponses visibles. Sur un sujet comme celui-ci, où les premières réponses ont toutes été supprimées, on se retrouve avec une page entière d’espaces réservés vides au lieu de contenu réel.

Le paramètre est bien activé — l’endpoint a renvoyé un code 200 au lieu de 404.

Le coupable semble être apply_visibility dans NestedReplies::TreeLoaderscope.unscope(where: :deleted_at) récupère tous les messages supprimés dans l’arbre. Cela a du sens pour un message parent supprimé qui contient encore des réponses actives, mais cela conserve aussi les messages feuilles supprimés et les branches entièrement supprimées, qui occupent des places dans la fenêtre ROOTS_PER_PAGE (et sont comptées dans has_more_roots).

Pour les utilisateurs non-administrateurs, il me semble qu’il faudrait supprimer un message supprimé à moins qu’il n’ait au moins un descendant non supprimé — ne le conserver que si son total_descendant_count visible est supérieur à 0. NestedViewPostStat exclut déjà les descendants supprimés/chuchotés de ce comptage, donc aucune requête supplémentaire n’est nécessaire.

Il faudrait appliquer cela dans les trois endroits qui construisent la page pour éviter d’obtenir des pages incomplètes : root_posts_scope, batch_preload_tree, et la partie de remplissage de page / has_more_roots. Le chemin pour les administrateurs reste inchangé pour la récupération.

Honnêtement, ça m’a fait tourner en rond pendant un moment — j’étais persuadé que mon client mobile était bugé, puisque les commentaires restaient vides sur certains sujets tout en fonctionnant parfaitement sur d’autres. Ça m’a pris un peu de temps pour comprendre que c’était l’endpoint qui renvoyait une page complète de placeholders supprimés, et pas un problème de mon côté.