@ethora/chat-component-rn 26.7.8 → 26.7.10

package/src/roomStore/roomsSlice.ts

@@ -2,6 +2,7 @@ import { createAsyncThunk, createSlice, PayloadAction, type Slice } from '@redux
 import type { WritableDraft } from 'immer';
 import { EditAction, HistoryPreloadState, IMessage, IRoom } from '../types/types';
 import { insertMessageWithDelimiter } from '../helpers/insertMessageWithDelimiter';
+import { msgSortableMs } from '../helpers/msgSortableMs';
 import type XmppClient from '../networking/xmppClient';
 
 // Per-room runtime message cap. Mirrors the persistence layer's
@@ -142,7 +143,6 @@ function mergeHistoryIntoCache(
   const ex = stripCallSignals(existing);
   const fe = stripCallSignals(fetched);
 
-  const pending = ex.filter((m) => m?.pending);
   const realExisting = ex.filter(
     (m) => m && !m.pending && m.id !== 'delimiter-new'
   );
@@ -151,6 +151,29 @@ function mergeHistoryIntoCache(
   // Nothing usable came back → keep the cache exactly as it was.
   if (realFetched.length === 0) {return ex;}
 
+  // Optimistic sends are preserved across a history merge - EXCEPT the
+  // ones the fetched page proves the server already has. That happens
+  // whenever a send reached the server but its echo did not reach us
+  // before the process died: the optimistic bubble is restored from disk
+  // still `pending: true` (and, since bug #39, flagged failed at boot),
+  // while MAM hands back the very same message under its ARCHIVE id.
+  // Keying only on `id` never matched those two, so the room ended up
+  // showing the message twice - once for real and once as a bubble stuck
+  // on "sending…"/"Failed" that nothing could ever clear. The archived
+  // copy carries our original stanza id as `xmppId` (getDataFromXml), so
+  // match on that too and drop the local ghost.
+  const fetchedKeys = new Set<string>();
+  for (const m of realFetched) {
+    if (m?.id != null) {fetchedKeys.add(String(m.id));}
+    if ((m as any)?.xmppId) {fetchedKeys.add(String((m as any).xmppId));}
+  }
+  const pending = ex.filter(
+    (m) =>
+      m?.pending &&
+      !fetchedKeys.has(String(m.id)) &&
+      !(m.xmppId && fetchedKeys.has(String(m.xmppId)))
+  );
+
   const byMs = (a: IMessage, b: IMessage) =>
     msgSortableMs(a) - msgSortableMs(b);
   const capTail = (arr: IMessage[]) =>
@@ -214,6 +237,33 @@ export interface RoomMessagesState {
   // — see `applyPrivateStoreMarkers`. Re-fetched every init/reconnect,
   // so it is intentionally NOT persisted.
   privateStoreMarkers: Record<string, number>;
+  // The single source of truth for "read up to here, but the user
+  // hasn't reached the bottom yet" (`{ roomJID: boundaryMs }`).
+  // Set by MessageList (via ChatRoom's `onReadBoundaryChange`) the
+  // moment the user first scrolls away from the bottom, to the
+  // msgSortableMs of the newest message they'd actually seen. Every
+  // path that stamps a read marker for a room the user is leaving
+  // (ChatRoom unmount, xmppProvider's AppState background handler and
+  // `isVisible=false` handler, the live `advance()` effect, and
+  // `useChatRoomFocus`'s `leaveRoom`) must consult this instead of
+  // unconditionally stamping "the newest acked message" - otherwise
+  // leaving a room while scrolled up marks messages the user never
+  // reached as read (customer #42, a regression of #33 reintroduced by
+  // #38's server-timestamp marker). See `getReadMarkerTimestamp` in
+  // helpers/getServerReadTimestamp.ts.
+  //
+  // Cleared when the boundary no longer applies: the user scrolls back
+  // to the bottom, the visible room changes, or the room is truly left
+  // (ChatRoom unmounts, or a tab-navigator focus hook releases the
+  // room). NOT cleared merely because the app backgrounds or a host's
+  // `isVisible` flips false - MessageList typically stays mounted
+  // through those, so its own scroll-tracking ref (the only thing that
+  // could re-derive this value) is still intact and the boundary must
+  // stay in sync with it. Deliberately NOT persisted (this key isn't
+  // read by `persistence.ts`, which only ever picks `rooms` back out of
+  // this slice) - it's meaningless across a process restart, where
+  // MessageList always mounts fresh at the bottom.
+  readBoundaries: Record<string, number>;
 }
 
 const initialState: RoomMessagesState = {
@@ -230,6 +280,7 @@ const initialState: RoomMessagesState = {
   },
   pendingNotificationJid: null,
   privateStoreMarkers: {},
+  readBoundaries: {},
 };
 
 const isValidRoomJid = (jid: unknown): jid is string => {
@@ -496,7 +547,7 @@ const reducers = {
           state.visibleRoomJID === roomJID
             ? null
             : lastViewedValue
-              ? new Date(lastViewedValue)
+              ? lastViewedValue
               : null;
 
         insertMessageWithDelimiter(roomMessages, message, lastViewedTimestamp);
@@ -514,6 +565,7 @@ const reducers = {
       state.rooms = {};
       state.visibleRoomJID = null;
       state.privateStoreMarkers = {};
+      state.readBoundaries = {};
       state.isUnreadSyncing = false;
     },
     setComposing(
@@ -580,7 +632,19 @@ const reducers = {
      *
      * Monotonic: a marker only ever moves a baseline FORWARD, so a stale
      * server value can't resurrect already-read messages and a more-recent
-     * local read (tab blur stamping Date.now()) always wins.
+     * local read (tab blur stamping the server read timestamp) always wins.
+     *
+     * Bug #38 self-heal: forward-only is correct for a SANE existing
+     * value, but a device whose clock was ahead may have already stamped
+     * a marker in the future (either persisted locally from a previous
+     * session, or fetched from the server before this fix existed). To
+     * "only ever move forward" from a corrupt future value is to never
+     * move at all - the room would stay stuck at `unreadMessages: 0`
+     * forever. When the room is loaded, detect a marker that sits well
+     * past the newest message we actually know it has and waive the
+     * forward-only check for that one comparison, so the incoming
+     * (already-clamped, see xmppClient.getChatsPrivateStoreRequestStanza)
+     * value can correct it even though it's numerically smaller.
      */
     applyPrivateStoreMarkers: (
       state: WritableDraft<RoomMessagesState>,
@@ -592,20 +656,72 @@ const reducers = {
       for (const jid of Object.keys(markers)) {
         const ts = Number(markers[jid]);
         if (!jid || !Number.isFinite(ts) || ts <= 0) {continue;}
+
+        const room = state.rooms[jid];
+        const newestKnownMs = room ? newestAckedMessageMs(room.messages) : 0;
+        // Mirrors isCorruptFutureReadMarker in helpers/getServerReadTimestamp.ts
+        // (duplicated to avoid a roomStore <-> helpers import cycle):
+        // BOTH signals are required. "Further ahead than the newest
+        // message this room has locally" happens all the time on a room
+        // whose history hasn't synced yet, and healing on that alone
+        // would drop a legitimate marker another device wrote after
+        // reading newer messages. A real read marker can never be ahead
+        // of real time, so that second signal is what distinguishes a
+        // stale cache from a wrong clock.
+        const nowMs = Date.now();
+        const looksCorrupt = (existing: number) =>
+          newestKnownMs > 0 &&
+          existing > newestKnownMs + FUTURE_MARKER_TOLERANCE_MS &&
+          existing > nowMs + FUTURE_MARKER_TOLERANCE_MS;
+
         // Remember the marker so rooms that load LATER (via addRoom)
         // inherit it even though they don't exist in the store yet.
-        if (ts > (state.privateStoreMarkers[jid] || 0)) {
+        const cachedMarker = state.privateStoreMarkers[jid] || 0;
+        if (ts > cachedMarker || looksCorrupt(cachedMarker)) {
           state.privateStoreMarkers[jid] = ts;
         }
         // Upgrade an already-loaded room's baseline + recompute its badge.
-        // Only ever forward, so a later local read isn't clobbered.
-        const room = state.rooms[jid];
-        if (room && ts > (room.lastViewedTimestamp || 0)) {
+        // Forward-only, unless the room's CURRENT baseline is itself the
+        // corrupt value being corrected.
+        if (room && (ts > (room.lastViewedTimestamp || 0) || looksCorrupt(room.lastViewedTimestamp || 0))) {
           room.lastViewedTimestamp = ts;
           room.unreadMessages = countNewerMessages(room.messages, ts);
         }
       }
     },
+    /**
+     * Set (or clear) the "read up to here, but not further" boundary for
+     * a room - see `readBoundaries` on `RoomMessagesState` for the full
+     * contract. `ts` is the msgSortableMs of the newest message the user
+     * actually reached before scrolling away from the bottom; `null`/`0`
+     * clears it (the user is at the bottom, or nothing was reached yet).
+     */
+    setReadBoundary: (
+      state: WritableDraft<RoomMessagesState>,
+      action: PayloadAction<{ jid: string; ts: number | null }>
+    ) => {
+      const { jid, ts } = action.payload;
+      if (!jid) {return;}
+      if (!state.readBoundaries) {state.readBoundaries = {};}
+      if (typeof ts === 'number' && Number.isFinite(ts) && ts > 0) {
+        state.readBoundaries[jid] = ts;
+      } else {
+        delete state.readBoundaries[jid];
+      }
+    },
+    /**
+     * Release a room's read boundary once it has been consumed by a
+     * genuine "leave" (ChatRoom unmount, or a tab-navigator focus hook
+     * switching to a different room) - see `readBoundaries` for why the
+     * background/`isVisible=false` paths deliberately do NOT call this.
+     */
+    clearReadBoundary: (
+      state: WritableDraft<RoomMessagesState>,
+      action: PayloadAction<{ jid: string }>
+    ) => {
+      const { jid } = action.payload;
+      if (jid && state.readBoundaries) {delete state.readBoundaries[jid];}
+    },
     setRoomRole: (
       state: WritableDraft<RoomMessagesState>,
       action: PayloadAction<{ chatJID: string; role: string }>
@@ -699,6 +815,7 @@ const reducers = {
       state.isLoading = false;
       state.isUnreadSyncing = false;
       state.privateStoreMarkers = {};
+      state.readBoundaries = {};
     },
     setActiveMessage: (
       state: WritableDraft<RoomMessagesState>,
@@ -820,27 +937,13 @@ export const roomsStore: Slice<RoomMessagesState, typeof reducers, 'roomMessages
   reducers,
 });
 
-// Count messages strictly newer than the given millisecond timestamp.
-// Uses `msg.id` (server-authoritative microsecond timestamp prefixed by
-// 13-digit millis — see helpers/dateComparison `getHighResolutionTimestamp`)
-// because `msg.date` can be derived client-side (createMessageFromXml
-// falls back to `Date.now()` for realtime stanzas without a `date`
-// attr), which makes the comparison drift vs what the server assigned.
-// Excludes the "delimiter-new" sentinel, pending sends, and the current
-// user's own messages (parity with unreadMiddleware's isOwnMessage
-// filter — without this, the reducer and the middleware disagree about
-// the count and we get a flicker as the badge gets written twice with
-// different values on every message).
-export const msgSortableMs = (msg: any): number => {
-  const id = String(msg?.id || '');
-  const m = /^(\d{13})/.exec(id);
-  if (m) {return Number(m[1]);}
-  if (msg?.date) {
-    const t = new Date(msg.date as any).getTime();
-    if (Number.isFinite(t)) {return t;}
-  }
-  return 0;
-};
+// Re-exported for backward compatibility - every existing call site
+// imports `msgSortableMs` from here. The implementation now lives in
+// helpers/msgSortableMs.ts (imported above), so insertMessageWithDelimiter.ts
+// (which this file itself imports) can use the SAME ordering source
+// without a roomStore <-> helpers import cycle. See that file for the
+// full rationale (server id vs. client `date`).
+export { msgSortableMs };
 
 const norm = (s: any): string => {
   if (s == null) {return '';}
@@ -872,6 +975,31 @@ const isOwn = (
   return false;
 };
 
+// Bug #38 tolerance: a stored read marker more than this far past the
+// newest message a room actually has is not "the user is a little
+// ahead" - it's a leftover from a device whose clock was wrong when it
+// stamped the marker. Kept in sync with (but duplicated from, to avoid
+// a roomStore ↔ helpers import cycle) FUTURE_READ_MARKER_TOLERANCE_MS
+// in helpers/getServerReadTimestamp.ts.
+const FUTURE_MARKER_TOLERANCE_MS = 5 * 60 * 1000;
+
+// Newest message in `messages` this room actually has proof the server
+// accepted - used only to sanity-check an already-stored read marker
+// against reality (see applyPrivateStoreMarkers's self-heal). Excludes
+// pending/optimistic sends via the `pending` flag alone: unlike
+// getServerReadTimestamp, this runs inside a reducer and can't reach
+// across to the roomHeapSlice slice, but `pending` already identifies
+// every optimistic send that matters for this comparison.
+const newestAckedMessageMs = (messages: IMessage[] | undefined): number => {
+  let newest = 0;
+  for (const m of messages || []) {
+    if (!m || m.id === 'delimiter-new' || m.pending) {continue;}
+    const ms = msgSortableMs(m);
+    if (ms > newest) {newest = ms;}
+  }
+  return newest;
+};
+
 const countNewerMessages = (
   messages: IMessage[],
   timestamp: number,
@@ -902,6 +1030,8 @@ export const {
   setUnreadSyncing,
   setLastViewedTimestamp,
   applyPrivateStoreMarkers,
+  setReadBoundary,
+  clearReadBoundary,
   setRoomNoMessages,
   setCurrentRoom,
   setVisibleRoom,

package/src/types/models/room.model.ts

@@ -79,7 +79,6 @@ export interface ApiRoom {
   jid?: string;
   participants?: number;
   icon?: string;
-  muted?: boolean;
 }
 
 export interface PostRoom {

package/src/types/types.ts

@@ -34,7 +34,6 @@ export interface IRoom {
   lastViewedTimestamp?: number;
   unreadMessages?: number;
   noMessages?: boolean;
-  muted?: boolean;
   role?: string;
   createdAt?: string | number | Date;
   updatedAt?: string | number | Date;
@@ -586,6 +585,20 @@ export interface IConfig {
   // `disableKeyboardAvoidingView` is set. Needs on-device tuning of any
   // `keyboardVerticalOffset`.
   keyboardStickyInput?: boolean;
+  // Bottom padding applied to the input dock (the composer's outer
+  // wrapper), on both iOS and Android. When a number is provided (0 is
+  // allowed) it is used verbatim on both platforms, overriding the
+  // built-in default below.
+  //
+  // Left unset, the default is:
+  //  - 0 when `disableKeyboardAvoidingView` is set, since the host owns
+  //    layout entirely and typically already places the chat above its
+  //    own chrome (e.g. a tab bar) - the built-in padding would just add
+  //    an extra gap between the composer and that chrome.
+  //  - otherwise unchanged: the iOS safe-area bottom inset, or a fixed
+  //    12dp gap on Android (`ANDROID_INPUT_DOCK_GAP`).
+  // Customer-reported #44.
+  inputDockPaddingBottom?: number;
   // The message list's FlatList uses keyboardDismissMode="interactive" by
   // default, so a drag can be used to pull the keyboard closed. Because
   // the list is `inverted`, an ordinary scroll gesture through history can