First step: see whether deleted messages (and their replies) are filtered on the frontend or backend - will determine how complex the fix is

First step: see whether deleted messages (and their replies) are filtered on the frontend or backend - will determine how complex the fix is

I can answer this immediately: it's all the front-end. The backend is delivering everything.

This should satisfy the spike of this issue:

In the Annotations tab of the sidebar, what you see by default is a list of top-level thread trees ordered by location in the document. A thread tree’s document location is based on some metadata within the thread’s topmost annotation—that annotation contains “selectors” that anchor the annotation to a location in the document. Replies do not have their own selectors; they are dependent on the topmost annotation for anchoring metadata.

When the topmost annotation (in a thread tree containing at least one reply ) is deleted, that , then, removes all location metadata for the entire thread—the affected thread tree cannot be sorted by location. Recent changes to sorting logic has made it possible to sort headless threads chronologically, but we fundamentally lack the data to be able to get them in location-sort order, which is key.

Because of this, one idea was surfacing these “headless threads” within the Orphans tab. I had hoped that this might be straightforward now that we have headless threads behaving somewhat sanely in the Notebook view (NB: Notebook uses a chronological sort).

Alas, I cannot see a straightforward path to this at present. Primarily this is due to an entrenched schizophrenia in the legacy code design of the client that both emphasizes and yet somehow conflates the difference between an annotation and a thread.

To determine whether to make the Orphans tab available (i.e. whether it shows up at all), the application’s “store” is queried. The question asked of it is: “OK, of all the annotations you know about, are any of them orphans? How many orphaned annotations do you know about?” The store operates entirely on annotations—it doesn’t know a lick about threads. And so in these cases of headless threads it would say “hey, I don’t know about any orphaned annotations.” To further complicate this: thread trees are built after a tab is selected. So asking “hey, are there any headless threads?” in addition to “hey, are there any orphaned annotations?” to determine whether to show the Orphans tab would be nonsensical as the answer to the former question is indeterminate at the time it’s being asked.

Once the orphans tab is active it would be possible to show these headless threads as part of the constructed thread tree, but there’s a fundamental chicken-and-egg situation of how we know that there are any orphans in the first place.

To reiterate: a headless thread entirely lacks an annotation in its topmost slot, and much of the application’s logic is based on annotations. The reason empty threads can show up easily enough in nested threads is that the presence and sorting of the entire thread is based on its topmost annotation.

There are ways to make this work in the long run, but I don’t see a quick path.

@lyzadanger this does indeed satisfy the spike, thank you! I have changed the title of this issue to a problem statement ("Headless" threads do not show in client sidebar) and will pull this back into the To Review column for next backlog meeting. Now that we know this is not a straightforward/small bit of work, we should reassess priority.

https://app.hubspot.com/contacts/6291320/ticket/420487232/