"Headless" threads do not show in the client sidebar

[mkdir-washington-edu]

What is the issue?
Right now the behaviors are -
Reply to a deleted reply:

• The deleted reply is replaced by "Message not available."
• The reply to the deleted reply is still available in the client sidebar.

Reply to a deleted top-level annotation:

• The deleted top-level annotation is not visible
• The reply to the deleted top-level annotation is not visible in the client sidebar.

We should make these behaviors the same. Particularly for users who have replied to a now-deleted top-level annotation, their comments and thoughts are no longer available to themselves or other users. To solve these issues, we could make the behavior of replies to deleted top-level annotations match the current behavior we use for a reply to a deleted reply.

To Reproduce this behavior

1. Create a top-level annotation.
2. Create a reply to the top-level annotation
3. Create a reply to the reply
4. Delete the reply to the top-level annotation. Note that the reply to the reply is still available on the page.
5. Delete the top-level annotation. Note that the whole thread disappears.

Screenshots

Additional context
https://hypothes-is.slack.com/archives/C03QZM0K4/p1589483503264100

[klemay]

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

[lyzadanger]

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.

[lyzadanger]

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.

[klemay]

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

[mkdir-washington-edu]

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

[mkdir-washington-edu]

Ran into some user feedback today (internal Slack thread) where an instructor replied to a student and the student deleted their top-level annotation. The instructor came away thinking that the student had managed to delete the instructor's annotation.