Diff comments are threaded together based on the in_reply_to relation
(which potentially expresses a tree structure) but are always displayed
linearly in the UI. This means that some comments in the middle of a
linear thread may be actually stored as leaves of a tree.
For example, the following thread of comments can be created if comments
two and three are created at nearly the same time.
Comment 1: thread root, unresolved,
┣ Comment 2: in reply to comment 1, unresolved,
┗ Comment 3: also in reply to comment 1, unresolved,
┗ Comment 4: in reply to comment 3, resolved
Because the thread is flattened, the resolved state of the thread should
be determined by the state of the chronologically latest comment (#4),
resulting in this thread being considered as resolved.
However, in a couple of locations, the resolved state is counted
differently. Namely, it finds the "leaf" comments -- that is, the
comments that are not marked as the parent of any other comment -- and
the number of unresolved threads is determined as the number of
unresolved leaves.
This approach was used by:
- ChangeComments#computeUnresolvedNum in the UI, which determines
the string stating the number of unresolved threads in a file row.
- ChangeData#unresolvedCommentCount in the Java server code, which
determines, among other things, the value of the
unresolved_comment_count change detail property, as well as the Prolog
fact used by the Prolog recipe that requires all comments to be
resolved before a change can be submitted.
Instead, the unresolved thread logic is modified to group comments into
flat threads, and consider the resolved state of each one based on the
chronologically final comment, irregardless of the leaves.
Bug: Issue 8472
Change-Id: I2788fdb22ecfd56f0b3da763790a7732ec73be33
452be95c9d