Die verschachtelte Antwortansicht (/n/) füllt Seiten mit Platzhaltern für gelöschte Beiträge auf, die die flache Ansicht weglässt

Wenn du das Thema des @angus Custom Wizard Plugin als anonymen Benutzer in der verschachtelten Antwortansicht aufrufst: https://meta.discourse.org/n/-/73345.json?page=0&sort=old

/n/-/73345.json?page=0&sort=old liefert 20 Stammbeiträge zurück, und jeder einzelne ist ein gelöschter Platzhalter — leeres cooked, kein Autor, total_descendant_count: 0. Somit besteht die gesamte erste Seite aus leeren „entfernten“ Zeilen.

Die flache Ansicht derselben Beiträge zeigt gar nichts (Beitrag #2 springt direkt zu verwandten Themen), also werden diese dort korrekt ausgeblendet. Die verschachtelte Ansicht behält sie jedoch bei und zählt sie zur Seite, was die Diskrepanz darstellt.

Anscheinend lädt der Tree-Loader gelöschte Beiträge absichtlich (um einen gelöschten Elternbeitrag sichtbar zu halten, wenn er noch aktive Antworten darunter hat), aber er behält auch gelöschte Beiträge, die keine sichtbaren Antworten mehr haben. Bei einem Thema wie diesem, bei dem alle frühen Antworten gelöscht wurden, erhält man am Ende eine volle Seite mit leeren Platzhaltern statt tatsächlichem Inhalt.

Die Einstellung ist definitiv aktiv — das Endpoint hat 200 statt 404 zurückgegeben.

Der Auslöser scheint apply_visibility in NestedReplies::TreeLoader zu sein — das scope.unscope(where: :deleted_at) zieht jeden gelöschten Beitrag in den Baum. Das macht Sinn für einen gelöschten Elternbeitrag, der noch aktive Antworten darunter hat, aber es behält auch gelöschte Blätter und vollständig gelöschte Zweige, und diese belegen Plätze im ROOTS_PER_PAGE-Fenster (und zählen zu has_more_roots).

Für Nicht-Mitarbeiter solltest du einen gelöschten Beitrag fallen lassen, es sei denn, er hat mindestens einen nicht gelöschten Nachkommen — behalte ihn nur, wenn seine sichtbare total_descendant_count > 0 ist. NestedViewPostStat schließt gelöschte/Flüstern-Nachkommen bereits von dieser Zählung aus, sodass keine zusätzliche Abfrage nötig ist.

Dies müsste an den drei Stellen angewendet werden, die die Seite aufbauen, damit keine kurzen Seiten entstehen: root_posts_scope, batch_preload_tree und der Bereich zum Auffüllen der Seite / has_more_roots. Der Pfad für Mitarbeiter bleibt wie bisher für die Wiederherstellung.

Ehrlich gesagt hat mich das eine Weile lang im Kreis gejagt – ich war überzeugt, dass mein mobiler Client defekt war, da die Kommentare in bestimmten Themen einfach leer blieben, während sie in anderen einwandfrei funktionierten. Es dauerte eine Weile, bis ich begriff, dass das Problem am Endpoint lag, der eine vollständige Seite mit gelöschten Platzhaltern zurücklieferte, und nicht an meiner Seite.