Incorporate PR changes

Author: compulim

docs/SORTING.md

@@ -1,28 +1,28 @@
-## How activities are being grouped?
+## How are activities grouped?
 
 Before sorting, activities are grouped as a unit:
 
-- Activities within same part grouping will be inserted next to each other
+- Activities within the same part grouping are inserted next to each other
    - Order is based on the `position` property
    - Logical timestamp of the part grouping is the "maximum logical timestamp" of all parts
-   - Parts can contains livestream session or ungrouped activities
-- Activities within same livestream session will be inserted next to each other
+   - Parts can contain livestream session or ungrouped activities
+- Activities within the same livestream session will be inserted next to each other
    - Order is based on the `streamSequence` property
    - Logical timestamp of the livestream session is the logical timestamp of the finalizing activity (if any), or the logical timestamp of the first activity
       - In other words, livestream will be reordered when they are inserted for the first time, or when they are finalized
       - Interim updates will not reorder the livestream to avoid too much flickering
-- All other activities are not grouped, they are unit of themselves
+- All other activities are not grouped, they are individual units
 
-## How activities are being sorted?
+## How are activities sorted?
 
-Short answer: activities are sorted by logical timestamp on insertion.
+Short answer: activities are sorted by logical timestamp when inserted.
 
 Long answer:
 
-- For grouped activities (such as part grouping or livestream sessions), all activities within the group are treated as a unit
-- For ungrouped activities, each activity is a unit of itself
+- For grouped activities (such as part groupings or livestream sessions), all activities within the group are treated as a unit
+- For ungrouped activities, each activity is a unit on its own
 
-Units are sorted using logical timestamp on insertion. If the unit is already in the chat history, they will be removed before re-inserting.
+Units are sorted using their logical timestamp on insertion. If the unit is already in the chat history, they will be removed before being re-inserted.
 
 ## What is logical timestamp?
 
@@ -36,19 +36,19 @@ logicalTimestamp = activity.channelData['webchat:sequence-id'] ?? +new Date(acti
    -  This field represents the order of the activity in the chat history and can be a sparse number;
    -  This field is OPTIONAL, but RECOMMENDED;
    -  This field MUST be an integer number;
-   -  This field MUST be an unique number assigned by the chat service;
+   -  This field MUST be a unique number assigned by the chat service;
    -  This field SHOULD be consistent across all members of the conversation.
 1. Otherwise, `activity.timestamp: string`
    -  This field represents the server timestamp of the activity;
    -  This field is REQUIRED;
-   -  This field MUST be an ISO date time string, for example, `2000-01-23T12:34:56.000Z`;
+   -  This field MUST be an ISO date-time string, for example, `2000-01-23T12:34:56.000Z`;
    -  This field MUST be assigned by the chat service, a.k.a. server timestamp;
    -  This field SHOULD have resolution up to 1 millisecond;
    -  This field MUST be the same across all members of the conversation.
 1. Otherwise, `activity.localTimestamp: string`
    -  This field represents the local timestamp of an outgoing activity;
    -  This field is REQUIRED for all outgoing activities;
-   -  This field MUST be an ISO date time string, for example, `2000-01-23T12:34:56.000Z`;
+   -  This field MUST be an ISO date-time string, for example, `2000-01-23T12:34:56.000Z`;
    -  This field MUST be assigned by the sender, a.k.a. Web Chat;
    -  This field SHOULD have resolution up to 1 millisecond;
    -  This field MUST be the same across all members of the conversation.

packages/core/src/reducers/activities/sort/upsert.ts

@@ -111,7 +111,9 @@ function upsert(ponyfill: Pick<GlobalScopePonyfill, 'Date'>, state: State, activ
       );
 
       // This is a special case.
-      // In the future, we should revisit this and see how we should process this activity (or drop it.)
+      // TODO: [P1] Revisit this and see how we should process activity after the livestream is finalized.
+      //            1. Received a previous-and-valid revision while the livestream is finalized (probably should keep to maintain history)
+      //            2. Received a final activity while the livestream is already finalized (probably drop due to bad packet)
       // Related to /__tests__/html2/livestream/concludedLivestream.html.
       return state;
     }