840 lines
51 KiB
TypeScript
840 lines
51 KiB
TypeScript
// Per-topic pub-sub + subscription lifecycle, layered on top of connection.ts's connection-level
|
|
// pub-sub. Topic.onData/onInfo/etc. are single-slot callbacks exactly like Tinode.onConnect/etc.
|
|
// (see connection.ts's header comment) -- this module claims them once per topic and fans out to
|
|
// any number of subscribers, which is what hooks.ts's useSyncExternalStore-based hooks consume.
|
|
//
|
|
// Subscription lifecycle mirrors the old app's (verified against its tinode-web.jsx/messages-view.jsx):
|
|
// - The `me` topic is subscribed once per session, metadata only (no message bodies).
|
|
// - Every contact gets a one-shot "preview" subscription (withLaterData(1)) so the chat list can
|
|
// show a last-message preview; it is never explicitly left afterward.
|
|
// - Opening a conversation subscribes with a full history page. A topic already subscribed (from
|
|
// its preview prefetch) has its subscribe() short-circuited by the SDK if called again with new
|
|
// getParams -- so this always leaves first when already subscribed, then resubscribes.
|
|
import type { Contact, StoredMessage, Topic } from 'tinode-sdk';
|
|
|
|
import { getGroup } from '@/lib/api/groups';
|
|
import { MESSAGES_PAGE } from '@/lib/config';
|
|
|
|
import { getTinode, onReauthenticated, onTinodeReset } from './connection';
|
|
|
|
const topicListeners = new Map<string, Set<() => void>>();
|
|
const anyTopicListeners = new Set<() => void>();
|
|
const wiredTopics = new WeakSet<Topic>();
|
|
const previewPrefetched = new Set<string>();
|
|
const messageSnapshots = new Map<string, StoredMessage[]>();
|
|
|
|
let activeConversationTopic: string | null = null;
|
|
|
|
/** Set by ConversationView on mount/unmount -- "is the user genuinely looking at this exact
|
|
* conversation right now" (topic open AND tab visible), consumed both by lib/notifications/push.ts
|
|
* (suppress a desktop notification for something already on screen) and by the me.onPres correction
|
|
* below (don't fight the SDK's auto-read-mark for the ONE conversation actually being watched). Lives
|
|
* here rather than in push.ts because topics.ts itself now also needs to read it, and push.ts already
|
|
* depends on topics.ts -- the reverse would be a cycle. */
|
|
export function setActiveConversationTopic(topicId: string | null) {
|
|
activeConversationTopic = topicId;
|
|
}
|
|
|
|
export function getActiveConversationTopic(): string | null {
|
|
return activeConversationTopic;
|
|
}
|
|
|
|
/**
|
|
* The other party's real `usr...` id for a P2P conversation -- NOT the same as `topic.name` once a
|
|
* conversation has any real history. Real, live-confirmed bug this fixes: a P2P topic addressed by
|
|
* the peer's own `usr...` id (the only address that exists before the very first subscribe -- e.g.
|
|
* straight from a friend's profile) gets renamed by the SDK to a real, opaque `p2p...` name the
|
|
* instant `subscribe()` succeeds (see openConversation's own doc comment on this same rename). Every
|
|
* P2P conversation with actual history is addressed by this `p2p...` form from then on -- but reading
|
|
* tinode.dev.js confirms `Topic.topicType()`'s prefix table has no `p2p` entry at all (only `usr` maps
|
|
* to the P2P type), so `topic.isP2PType()`/`topic.p2pPeerDesc()` silently return false/undefined for
|
|
* every one of these topics, and code that assumed "the P2P topic name IS the peer's user id" (true
|
|
* only for the brief pre-first-subscribe window) breaks the moment that assumption stops holding --
|
|
* confirmed live: `GET /users/{topicName}/profile` 404s, `friends.find(f => f.user_id === topicName)`
|
|
* never matches, block/remark/avatar all silently target a user id that doesn't exist.
|
|
*
|
|
* Returns `undefined` (never `topic.name` as a guess) when the subscriber list isn't populated yet --
|
|
* live-confirmed this matters: on the render right after navigating straight to a `p2p...`-named
|
|
* conversation, `subscribers()` can still be empty for the one or two renders before the subscribe
|
|
* response fills it in, and returning `topic.name` as a placeholder there just fires the exact same
|
|
* doomed `GET /users/{p2p...}/profile` request this function exists to prevent, a render later. Every
|
|
* caller already guards its query with `enabled: !!peerUserId`, so `undefined` correctly makes it wait
|
|
* instead of firing once with a value it knows is wrong.
|
|
*/
|
|
export function getP2PPeerUserId(topic: Topic, myUserId: string | null | undefined): string | undefined {
|
|
if (topic.name.startsWith('usr')) return topic.name;
|
|
let peer: string | undefined;
|
|
topic.subscribers((sub) => {
|
|
if (!peer && sub.user !== myUserId) peer = sub.user;
|
|
});
|
|
return peer;
|
|
}
|
|
|
|
const confirmedReadSeq = new Map<string, number>();
|
|
// Tinode reserves this sequence and higher values for optimistic local messages.
|
|
const LOCAL_SEQID = 0xfffffff;
|
|
|
|
export function getConfirmedRead(topicName: string): number {
|
|
const seq = confirmedReadSeq.get(topicName) || 0;
|
|
return seq > 0 && seq < LOCAL_SEQID ? seq : 0;
|
|
}
|
|
|
|
/** Repair an SDK contact polluted by a local sequence before it reaches the list or sync snapshot. */
|
|
export function repairContactReadState(contact: Pick<Contact, 'seq' | 'read' | 'recv' | 'unread'>): void {
|
|
const seq = contact.seq || 0;
|
|
const read = contact.read || 0;
|
|
const recv = contact.recv || 0;
|
|
if (read < LOCAL_SEQID && recv < LOCAL_SEQID && read <= seq && recv <= seq && (contact.unread || 0) >= 0) return;
|
|
contact.read = Math.min(Math.max(0, read), seq);
|
|
contact.recv = Math.min(Math.max(contact.read, recv), seq);
|
|
contact.unread = Math.max(0, seq - contact.read);
|
|
}
|
|
|
|
/**
|
|
* This app's OWN independent record of "the user has genuinely seen up to `seq` in this topic" --
|
|
* tracked separately from the SDK's own `read`/`unread` fields because those get silently advanced by
|
|
* a mechanism this app doesn't want for a conversation that's merely open in a backgrounded tab (see
|
|
* the me.onPres override in subscribeMeTopic below for the full story). Callers: openConversation
|
|
* seeds this the moment a conversation is freshly opened (opening one always means "I've seen
|
|
* everything up to here", regardless of tab visibility, since you can only open one by clicking on it
|
|
* while looking at the page); ConversationView additionally bumps it whenever it calls noteRead() while
|
|
* actually visible.
|
|
*/
|
|
export function markConfirmedRead(topicName: string, seq: number) {
|
|
if (!Number.isInteger(seq) || seq <= 0 || seq >= LOCAL_SEQID) return;
|
|
const prev = getConfirmedRead(topicName);
|
|
if (seq > prev) confirmedReadSeq.set(topicName, seq);
|
|
}
|
|
|
|
// Live-confirmed root cause of a real reported bug ("聊天消息框滚动到顶部或底部时UI会抖动闪烁"):
|
|
// `topic.onData = notify` (wireTopicCallbacks below) fires once per INDIVIDUAL message, not once per
|
|
// batch -- confirmed by instrumenting a real `loadOlder()` page fetch (24 older messages): the DOM
|
|
// mutated in ~14 separate small steps over ~400ms, each one growing `scrollHeight` a little and each
|
|
// one racing the OTHER open effect that reads it (loadOlder's own scroll-compensation, and
|
|
// ConversationView's separate "autoscroll to bottom" effect) -- neither gets a stable, final
|
|
// `scrollHeight` to work with until the whole page has actually finished arriving, so each of the ~14
|
|
// intermediate re-renders nudges `scrollTop` again, which is what actually reads as "shaking" rather
|
|
// than one clean jump. This wasn't reproducible by reasoning about a single `getMessagesPage()` call
|
|
// in isolation -- it only showed up instrumenting `scrollTop` across a real fetch.
|
|
// Fix: coalesce any notifications that land within the same animation frame into one flush, so a
|
|
// burst of N `onData` calls (initial page load, `loadOlder()`, or a fast run of incoming messages)
|
|
// triggers at most one re-render per frame instead of N -- imperceptible as a delay, but it means
|
|
// `scrollHeight` is only ever read by a re-render once it reflects everything that arrived so far in
|
|
// that frame, not some in-between partial state. `messageSnapshots.delete` stays synchronous (it's
|
|
// pure cache invalidation, not a re-render) so a snapshot read between two notifications in the same
|
|
// frame still sees the latest data, only the LISTENER callbacks (which is what schedules React's own
|
|
// re-render) are what get batched.
|
|
const pendingTopicNotifications = new Set<string>();
|
|
let pendingAnyNotification = false;
|
|
let notifyFrameScheduled = false;
|
|
|
|
function flushTopicNotifications() {
|
|
notifyFrameScheduled = false;
|
|
const topics = [...pendingTopicNotifications];
|
|
pendingTopicNotifications.clear();
|
|
const flushAny = pendingAnyNotification;
|
|
pendingAnyNotification = false;
|
|
for (const topicName of topics) {
|
|
topicListeners.get(topicName)?.forEach((cb) => cb());
|
|
}
|
|
if (flushAny) {
|
|
anyTopicListeners.forEach((cb) => cb());
|
|
}
|
|
}
|
|
|
|
function notifyTopic(topicName: string) {
|
|
messageSnapshots.delete(topicName);
|
|
pendingTopicNotifications.add(topicName);
|
|
pendingAnyNotification = true;
|
|
if (!notifyFrameScheduled) {
|
|
notifyFrameScheduled = true;
|
|
// Live-confirmed real bug (surfaced while testing an unrelated group-rename fix, in a webview whose
|
|
// frame compositing was paused, i.e. genuinely not painting -- not just an ordinary backgrounded
|
|
// browser tab): a `requestAnimationFrame` scheduled while the page isn't compositing frames can go
|
|
// uncalled indefinitely rather than merely deferred-until-visible. Since `notifyFrameScheduled` only
|
|
// resets to false inside the callback, one dropped frame permanently wedges this guard, silently
|
|
// freezing EVERY future topic-list update (not just the group name) until a full page reload -- data
|
|
// kept arriving and updating correctly underneath (confirmed live: `me.contacts()` had the right
|
|
// data the whole time), only the UI never found out. `document.hidden` costs nothing to check and
|
|
// `setTimeout` is never silently dropped the way this rAF was, so route through it whenever the page
|
|
// isn't visible; keep `requestAnimationFrame` for the visible case since that's what actually gives
|
|
// the intended one-flush-per-paint batching this function exists for.
|
|
if (typeof document !== 'undefined' && document.hidden) {
|
|
setTimeout(flushTopicNotifications, 0);
|
|
} else {
|
|
requestAnimationFrame(flushTopicNotifications);
|
|
}
|
|
}
|
|
}
|
|
|
|
export function subscribeTopicChanges(topicName: string, callback: () => void): () => void {
|
|
let set = topicListeners.get(topicName);
|
|
if (!set) {
|
|
set = new Set();
|
|
topicListeners.set(topicName, set);
|
|
}
|
|
set.add(callback);
|
|
return () => set.delete(callback);
|
|
}
|
|
|
|
/** Fires on ANY topic's change -- used by the chat list, which derives its rows from every contact
|
|
* at once (`me.contacts()`) rather than tracking one topic in particular. */
|
|
export function subscribeAnyTopicChange(callback: () => void): () => void {
|
|
anyTopicListeners.add(callback);
|
|
return () => anyTopicListeners.delete(callback);
|
|
}
|
|
|
|
export interface RawTopicInfo {
|
|
what: 'read' | 'recv' | 'kp' | 'call' | 'im' | 'group';
|
|
seq?: number;
|
|
from?: string;
|
|
event?: string;
|
|
payload?: Record<string, unknown>;
|
|
}
|
|
const infoListeners = new Set<(topicName: string, info: RawTopicInfo) => void>();
|
|
|
|
/** Raw `{info}` payloads (read/recv/kp/call), forwarded verbatim -- unlike `subscribeAnyTopicChange`/
|
|
* `subscribeTopicChanges`, which only signal "something changed, re-read the snapshot" for the
|
|
* chat-list/message-list hooks, calls.ts needs the actual `event`/`payload` fields off a `what:
|
|
* "call"` info to drive its own ringing/accept/hang-up state machine -- those aren't reconstructable
|
|
* from a message snapshot re-read the way a new chat message is. */
|
|
export function subscribeTopicInfo(callback: (topicName: string, info: RawTopicInfo) => void): () => void {
|
|
infoListeners.add(callback);
|
|
return () => infoListeners.delete(callback);
|
|
}
|
|
|
|
/**
|
|
* The SDK only routes an incoming {info} packet into Topic._routeInfo (and from there to
|
|
* topic.onInfo -> the infoListeners fanout above) when the packet's topic name is already in the
|
|
* client's topic cache -- tinode.dev.js's dispatcher does `#cacheGet('topic', pkt.info.topic)` and
|
|
* silently drops the frame on a miss. Friend-request signals (Zentao #3) arrive with `topic` set to
|
|
* the RECIPIENT'S OWN user id (publishIMRelationEvent -> sessionStore.DeliverToUser, i.e. addressed
|
|
* to the user's `me` topic), but the me topic is cached under the literal "me" -- so that lookup
|
|
* misses every time and the frame never reached any info listener. Live-confirmed 2026-09-18: the
|
|
* SDK's own logger showed the raw `friend.request.rejected` frame arriving on the socket while
|
|
* AppShell's subscribeTopicInfo callback never fired. The connection-level onInfoMessage hook sees
|
|
* EVERY info packet regardless of cache state, so forward ONLY the frames the topic-level path will
|
|
* not deliver (isTopicCached false) to the same infoListeners: cached topics keep flowing through
|
|
* topic.onInfo exactly once (no duplicates), uncached ones stop being silently lost. Both members
|
|
* are real SDK runtime members absent from the hand-maintained .d.ts (same cast rationale as the
|
|
* read/unread reads in getChatListSnapshot). Installed from subscribeMeTopic -- the one point every
|
|
* login flows through -- and re-installed there after resetTinode() rebuilds the instance.
|
|
*/
|
|
function installUncachedInfoFallback(t: unknown) {
|
|
const sdk = t as {
|
|
onInfoMessage?: ((info: RawTopicInfo & { topic: string }) => void) | null;
|
|
isTopicCached?: (topicName: string) => boolean;
|
|
};
|
|
sdk.onInfoMessage = (info) => {
|
|
if (info && sdk.isTopicCached && !sdk.isTopicCached(info.topic)) {
|
|
infoListeners.forEach((cb) => cb(info.topic, info));
|
|
}
|
|
};
|
|
}
|
|
|
|
const goneListeners = new Set<(topicName: string) => void>();
|
|
|
|
const newGroupListeners = new Set<(topicName: string) => void>();
|
|
|
|
/** Fires when reconcileMeSubs() (below) discovers a group topic this client has never seen before --
|
|
* the "you were just added to a group" case (Zentao/user-reported: "被拉入群时title的消息没有提示").
|
|
* Consumed by lib/notifications/push.ts to fire a desktop notification -- can't live there itself
|
|
* since push.ts already depends on topics.ts and the reverse would be a cycle, same reasoning as
|
|
* setActiveConversationTopic living here instead of in push.ts. */
|
|
export function subscribeNewGroupDiscovered(callback: (topicName: string) => void): () => void {
|
|
newGroupListeners.add(callback);
|
|
return () => newGroupListeners.delete(callback);
|
|
}
|
|
|
|
/** Fires once a topic is confirmed gone (group dissolved by anyone, or removed from this account) --
|
|
* the SDK's own `Topic#_gone()` clears the topic's public/private/messages and calls
|
|
* `onDeleteTopic()` (confirmed reading tinode.dev.js). Without ConversationView reacting to this,
|
|
* a member who stays on a group's conversation screen while someone else dissolves it just keeps
|
|
* looking at a now-defunct view -- `onMetaDesc`/`onPres`/etc. above only invalidate cached snapshots
|
|
* for re-render, they don't tell the currently-open screen it needs to navigate away entirely. */
|
|
export function subscribeTopicGone(callback: (topicName: string) => void): () => void {
|
|
goneListeners.add(callback);
|
|
return () => goneListeners.delete(callback);
|
|
}
|
|
|
|
/**
|
|
* Topics confirmed gone that `getChatListSnapshot` must never show again THIS session, no matter what
|
|
* re-creates a cache entry for the name afterward -- live-confirmed real race: `openConversation`'s
|
|
* own cleanup (`closeConversation`, fired by ConversationView's unmount effect as the redirect below
|
|
* unmounts it) calls `getTinode().getTopic(topicName)` again for its `.leave(false)` -- unconditionally,
|
|
* with no way to know this specific name should stay forgotten -- which by itself re-creates a fresh,
|
|
* empty stub the instant `cacheRemTopic` below has removed the old one, silently undoing the cleanup
|
|
* and leaving the exact same broken sidebar row behind. Excluding by name in the chat-list filter
|
|
* itself sidesteps that ordering race entirely rather than trying to make cleanup run strictly after
|
|
* every other thing that might touch this topic's cache entry.
|
|
*/
|
|
const goneTopicNames = new Set<string>();
|
|
|
|
/**
|
|
* Shared by every "this topic is confirmed gone" path below -- native `onDeleteTopic` (a real `{pres
|
|
* what:"gone"}`, which never actually happens for THIS backend's own group dissolve -- see the
|
|
* `group.dissolved` handling in wireTopicCallbacks' `onInfo` for why) and that custom path itself both
|
|
* call this, so cache cleanup can't accidentally happen on only one of them. Removing the topic from
|
|
* the SDK's cache matters even here (not just for the 404-before-ever-subscribing case forgetTopic
|
|
* covers) -- confirmed live: a passive member watching a group when someone else dissolves it now
|
|
* correctly gets bounced to /messages the instant it happens, but the group still lingered in their
|
|
* chat list afterward (raw topic id, "1970/1/1") until this was added, same broken-stub symptom, just
|
|
* reached via the live path instead of the refresh-into-already-gone one.
|
|
*
|
|
* Skips everything (including `goneListeners`) once `goneTopicNames` already has this name -- real,
|
|
* user-reported bug: leaving a group yourself (GroupDetailColumn's 退出群聊/解散群聊, which calls
|
|
* `forgetTopic` synchronously the instant its own REST call succeeds, see below) still leaves the
|
|
* server free to ALSO deliver a native/`group.dissolved` gone-signal for that same topic a moment
|
|
* later, since from the server's point of view your own subscription really did just end too. Left
|
|
* unguarded, that late-arriving signal would re-run `goneListeners` a second time for a topic already
|
|
* handled -- showing ConversationView's "该群聊已解散" toast (wrong wording for a leave you chose
|
|
* yourself, not a dissolve) on top of whatever that action's own success handler already did.
|
|
*/
|
|
function markTopicGoneAndNotify(topicName: string) {
|
|
if (goneTopicNames.has(topicName)) return;
|
|
goneTopicNames.add(topicName);
|
|
getTinode().cacheRemTopic(topicName);
|
|
notifyTopic(topicName);
|
|
goneListeners.forEach((cb) => cb(topicName));
|
|
}
|
|
|
|
/**
|
|
* For any topic THIS client already knows is gone without needing to be told by a server push --
|
|
* `openConversation()` rejecting with a 404 (see ConversationView's `isTopicGone` handling) because it
|
|
* was deep-linked/refreshed into after already being dissolved, or GroupDetailColumn's own 退出群聊/
|
|
* 解散群聊 success handlers calling this immediately rather than waiting on the async gone-signal that
|
|
* usually follows. Doesn't go through markTopicGoneAndNotify's `goneListeners` trigger -- every caller
|
|
* already has its own richer, action-specific way to notify+navigate (a 404 catch block with the real
|
|
* `err`; a mutation's own `onSuccess`), so firing goneListeners too would just re-run that a second
|
|
* time, and for the leave/disband callers specifically, with the WRONG generic "该群聊已解散" wording.
|
|
* Adding to `goneTopicNames` here first is exactly what makes markTopicGoneAndNotify's own guard above
|
|
* effective against whatever late server push for this same topic follows.
|
|
*/
|
|
export function forgetTopic(topicName: string): void {
|
|
goneTopicNames.add(topicName);
|
|
getTinode().cacheRemTopic(topicName);
|
|
notifyTopic(topicName);
|
|
}
|
|
|
|
function wireTopicCallbacks(topic: Topic) {
|
|
if (wiredTopics.has(topic)) return;
|
|
const notify = () => notifyTopic(topic.name);
|
|
topic.onData = notify;
|
|
topic.onInfo = (info) => {
|
|
notify();
|
|
if (info) infoListeners.forEach((cb) => cb(topic.name, info));
|
|
// Real, live-confirmed gap (user-reported: "被解散当时没有" [redirect] -- only a later manual
|
|
// refresh ever caught it): this backend's own group-dissolve notification (server/
|
|
// im_group_events.go's publishIMGroupRealtimeEvent) travels as a custom `{info what:"group"
|
|
// event:"group.dissolved"}` packet, NOT the native Tinode `{pres what:"gone"}` the SDK's own
|
|
// `_gone()`/`onDeleteTopic` chain below is built around. Confirmed by reading tinode.dev.js's
|
|
// `_routeInfo`: `what:"group"` matches none of its explicit switch cases (recv/read/kp/kpa/kpv/
|
|
// call), so nothing native reacts to it -- `onInfo(info)` still fires right after regardless, but
|
|
// until now nothing here recognized this specific shape either. A member who was ACTIVELY,
|
|
// PASSIVELY watching a group (never the one who dissolved it themselves -- that flow already
|
|
// navigates away on its own mutation success, which is why testing only as the dissolver always
|
|
// looked correct) got no live signal at all: only a later refresh, hitting openConversation's 404
|
|
// path (see ConversationView's isTopicGone), ever discovered it was gone. Reuses the exact same
|
|
// goneListeners subscribeTopicGone already exports, so ConversationView needs no changes at all.
|
|
// Live-confirmed follow-up bug: this path alone (unlike onDeleteTopic below) never actually
|
|
// cleared the SDK's own topic cache, so the redirect fired correctly but the dissolved group kept
|
|
// lingering in the sidebar as a broken stub ("g grpMc5uN_H6ASc 2人 1970/1/1") until markTopicGoneAndNotify
|
|
// was made to cover this path too.
|
|
const groupEvent = info as { what?: string; event?: string } | undefined;
|
|
if (groupEvent?.what === 'group' && groupEvent.event === 'group.dissolved') {
|
|
markTopicGoneAndNotify(topic.name);
|
|
}
|
|
// docs/IM-前后端对接文档.md:416,1256: recall/edit push a custom `{info what:"im",
|
|
// event:"message.recalled"|"message.edited", payload:{seq,version}}` to every other ONLINE
|
|
// topic member -- explicitly NOT a native Tinode mechanism (`_routeInfo`'s switch has no `"im"`
|
|
// case, confirmed reading tinode.dev.js the same way the group.dissolved gap above was), so
|
|
// nothing here ever picked it up before. `notify()` above still fired (it's unconditional), so a
|
|
// component watching this topic WOULD re-render -- but the SDK's own local message cache was
|
|
// never told the content changed, so it re-rendered the SAME stale pre-recall/pre-edit bubble.
|
|
// The doc's own instruction is explicit: "按 topic+seq+version 刷新本地消息，不要等待用户重新
|
|
// 进入会话才更新" -- live-confirmed this was exactly what was happening instead (recall/edit only
|
|
// ever showed up for the OTHER party after something unrelated caused a full resync, e.g.
|
|
// reopening the conversation). Reuses the exact `getMeta(...).withData(seq,seq+1,1)` targeted
|
|
// single-message refetch ConversationView's own jump-to-message feature already established.
|
|
if (info?.what === 'im' && (info.event === 'message.recalled' || info.event === 'message.edited')) {
|
|
const seq = info.payload?.seq;
|
|
if (typeof seq === 'number') {
|
|
topic.getMeta(topic.startMetaQuery().withData(seq, seq + 1, 1).build()).catch(() => {});
|
|
}
|
|
}
|
|
// docs/IM-前后端对接文档.md:1542 documents this push as `group.profile.updated`, but a real rename,
|
|
// live-instrumented (logging the raw `info` object as it arrived), showed the actual wire event is
|
|
// `{what:"group", event:"group.settings.updated"}` -- same doc-vs-wire drift already seen elsewhere
|
|
// in this backend. Matching the real event name fixes only half the bug: the sidebar/header name
|
|
// comes from `contact.public?.fn` (native SDK state, see ChatListColumn.tsx), which a REST-only
|
|
// mutation never touches for anyone, and the "obvious" fix -- `getMeta(startMetaQuery().withDesc()
|
|
// .build())`, the SDK's own sanctioned way to re-pull desc from the server -- was live-instrumented
|
|
// too and found to be genuinely broken against this backend: a consistent 504 timeout (~5.4s, every
|
|
// attempt, still failing 10+s after the write) on a brand-new topic, and on an established topic a
|
|
// fast-but-stale response whose `public.fn` still held the pre-rename name. Using the already-
|
|
// reliable REST `getGroup()` instead (confirmed live to return the fresh name immediately after a
|
|
// rename, every time) and applying it locally via `_processMetaDesc` -- the same internal method the
|
|
// SDK itself calls when a real `{meta desc}` response arrives, live-confirmed to correctly reach
|
|
// `me.contacts()` -- sidesteps the broken path entirely instead of routing through it.
|
|
if (groupEvent?.what === 'group' && groupEvent.event === 'group.settings.updated') {
|
|
getGroup(topic.name)
|
|
.then((data) => topic._processMetaDesc({ public: { fn: data.name, name: data.name } }))
|
|
.catch(() => {});
|
|
}
|
|
};
|
|
topic.onMetaDesc = notify;
|
|
// Only ever actually invoked on the `me` topic (the SDK reads `me.onMetaSub`/`me.onSubsUpdated`
|
|
// specifically, regardless of which topic's subscribe triggered it -- confirmed tinode.dev.js:
|
|
// 4654-4659) -- wiring it here on every topic is a no-op for anything else, same as onSubsUpdated
|
|
// right below, which already gets this same treatment. Without this, a brand-new P2P conversation
|
|
// reached by the other user's `usr...` id (no established topic yet) never tells the chat list a
|
|
// new contact exists the instant the server assigns its real `p2p...` name on first subscribe --
|
|
// the contact stays invisible in the sidebar, and ConversationView's own `contact` lookup (peer
|
|
// name, online status) keeps missing until some UNRELATED full resync happens to pick it up.
|
|
topic.onMetaSub = notify;
|
|
topic.onSubsUpdated = notify;
|
|
topic.onPres = notify;
|
|
topic.onAuxUpdated = notify;
|
|
topic.onAllMessagesReceived = notify;
|
|
topic.onDeleteTopic = () => {
|
|
markTopicGoneAndNotify(topic.name);
|
|
};
|
|
wiredTopics.add(topic);
|
|
}
|
|
|
|
/** Cached per topic; only recomputed when notifyTopic() invalidates it, so useSyncExternalStore's
|
|
* getSnapshot returns a stable reference between real changes instead of a new array every render. */
|
|
export function getMessagesSnapshot(topicName: string): StoredMessage[] {
|
|
let cached = messageSnapshots.get(topicName);
|
|
if (!cached) {
|
|
const topic = getTinode().getTopic(topicName);
|
|
cached = [];
|
|
topic.messages((msg) => cached!.push(msg));
|
|
messageSnapshots.set(topicName, cached);
|
|
}
|
|
return cached;
|
|
}
|
|
|
|
/** Deduped the same way openConversation/connect are -- subscribing the same `me` topic twice
|
|
* concurrently is the same non-idempotent-WS-call shape as those (currently reachable from
|
|
* RequireAuth.tsx/LoginPage.tsx, which don't overlap today, but this is cheap insurance against a
|
|
* future call site that does, e.g. a manual "reload contacts" retry button). */
|
|
let inFlightMeSubscribe: Promise<unknown> | null = null;
|
|
|
|
/** Call once at session start (after login) -- chat-list metadata only, no message bodies. */
|
|
export function subscribeMeTopic(): Promise<unknown> {
|
|
if (inFlightMeSubscribe) return inFlightMeSubscribe;
|
|
const tinode = getTinode();
|
|
installUncachedInfoFallback(tinode);
|
|
const me = tinode.getMeTopic();
|
|
wireTopicCallbacks(me);
|
|
// Read/recv/unread updates (e.g. from noteRead() when opening a conversation) travel through
|
|
// TopicMe's OWN single-slot callback, separate from onData/onInfo/onPres -- wireTopicCallbacks
|
|
// doesn't touch it. Without this, the chat list's unread badge/ordering goes stale after reading
|
|
// a conversation until some unrelated topic event happens to invalidate its cached snapshot.
|
|
me.onContactUpdate = () => notifyTopic(me.name);
|
|
// Real, live-confirmed bug (2026-09-16, reported directly): reading tinode-sdk's source, TopicMe's
|
|
// own `_routePres` handles a `{pres what:"msg"}` push -- the mechanism that updates a topic's unread
|
|
// count even when you're not actively viewing it -- by calling `cont._updateReceived(pres.seq,
|
|
// pres.act)`, which unconditionally sets `read = seq` (marks it AS READ) whenever `act` is falsy or
|
|
// refers to yourself. A conversation that's simply left OPEN (ConversationView mounted, topic
|
|
// actively subscribed) -- even sitting in a fully backgrounded tab nobody is looking at -- still gets
|
|
// this same presence push, and gets silently auto-marked read regardless of tab visibility: confirmed
|
|
// live, a message sent to a conversation left open in a backgrounded tab never bumped the unread
|
|
// count at all, defeating the tab-title/favicon/notification indicators this same session just built
|
|
// (ConversationView's own visibility-gated noteRead() call -- see its comment -- only prevents ITS
|
|
// OWN explicit read-marking; it has no way to intercept this separate, lower-level SDK mechanism).
|
|
// markConfirmedRead (see its own comment) is this app's independent record of when the user genuinely
|
|
// saw a topic. Right after the SDK's own (for this app's purposes, wrong) auto-mark runs, correct it
|
|
// back down to that record for any topic that isn't the one actually being looked at right now.
|
|
me.onPres = (pres: unknown) => {
|
|
notifyTopic(me.name);
|
|
const p = pres as { what?: string; src?: string } | undefined;
|
|
if (p?.what !== 'msg' || typeof p.src !== 'string') return;
|
|
const topicName = p.src;
|
|
const isBeingViewed = topicName === activeConversationTopic && document.visibilityState === 'visible';
|
|
if (isBeingViewed) return;
|
|
// Cast for the same reason getChatListSnapshot does -- read/unread/seq are real fields the SDK
|
|
// sets directly on the Topic instance at runtime, just not declared on this hand-maintained .d.ts.
|
|
const topic = getTinode().getTopic(topicName) as unknown as Contact;
|
|
repairContactReadState(topic);
|
|
const correctRead = getConfirmedRead(topicName);
|
|
if ((topic.read || 0) > correctRead) {
|
|
topic.read = correctRead;
|
|
topic.unread = Math.max(0, (topic.seq || 0) - correctRead);
|
|
notifyTopic(topicName);
|
|
}
|
|
};
|
|
inFlightMeSubscribe = me.subscribe(me.startMetaQuery().withLaterSub().withDesc().withTags().withCred().build()).finally(() => {
|
|
inFlightMeSubscribe = null;
|
|
});
|
|
return inFlightMeSubscribe;
|
|
}
|
|
|
|
/** Tracks prefetchPreview's own in-flight subscribe per topic, so openConversation (below) can wait
|
|
* for it to settle first instead of firing a second overlapping `{sub}` packet at the same topic --
|
|
* this is a real path, not just theoretical: ChatListColumn prefetches every visible contact's
|
|
* preview on render, and a deep link or fast click can open one of those same topics before its
|
|
* preview subscribe has resolved. */
|
|
const inFlightPreview = new Map<string, Promise<unknown>>();
|
|
|
|
/**
|
|
* One-shot per topic: subscribes just enough to learn its latest message for the chat-list preview.
|
|
* Deliberately never left afterward (matches the old app) -- simpler than tracking teardown for a
|
|
* subscription that's cheap to leave attached and likely to be reopened soon anyway.
|
|
*/
|
|
function prefetchPreview(topicName: string): void {
|
|
if (previewPrefetched.has(topicName)) return;
|
|
previewPrefetched.add(topicName);
|
|
const topic = getTinode().getTopic(topicName);
|
|
wireTopicCallbacks(topic);
|
|
const promise = topic.subscribe(topic.startMetaQuery().withLaterData(1).build()).catch(() => {
|
|
previewPrefetched.delete(topicName);
|
|
});
|
|
inFlightPreview.set(topicName, promise);
|
|
promise.finally(() => {
|
|
if (inFlightPreview.get(topicName) === promise) inFlightPreview.delete(topicName);
|
|
});
|
|
}
|
|
|
|
/**
|
|
* The SDK has no per-topic in-flight tracking of its own: `Topic.subscribe()` only short-circuits
|
|
* once `_attached` is already true, so two overlapping calls (React 19 StrictMode's mount->cleanup->
|
|
* remount runs every effect twice in dev, so openConversation() always overlaps with itself once per
|
|
* open; ChatListColumn's prefetchPreview and this both racing for the same just-deep-linked topic is
|
|
* the same shape in prod) would otherwise send two `{sub}` packets, and a `leave()` that lands before
|
|
* the first `subscribe()` resolves just rejects ("Cannot leave inactive topic") and no-ops instead of
|
|
* detaching. Tracked here so every caller for the same topic name shares one in-flight promise.
|
|
*/
|
|
const inFlightSubscribe = new Map<string, Promise<Topic>>();
|
|
|
|
/**
|
|
* Bumped by every openConversation() call, checked by closeConversation() after it's done waiting --
|
|
* without this, StrictMode's mount->cleanup->remount still breaks a freshly (re)opened conversation:
|
|
* cleanup-1 awaits the SAME shared inFlightSubscribe promise mount-2 is also relying on (they're
|
|
* deduped to one promise, per the comment above), and once it resolves, cleanup-1's queued
|
|
* continuation calls leave() unconditionally -- detaching the subscription mount-2 just established
|
|
* a moment earlier, with no error surfaced anywhere (confirmed by reading tinode.dev.js: `_attached`
|
|
* only flips true on a successful subscribe, and leave(false) while `_attached` is true really does
|
|
* send `{leave}` and reset it). The topic silently stops receiving live messages/receipts. Capturing
|
|
* the generation synchronously at closeConversation's call time and re-checking it after all awaits
|
|
* settle detects "a newer open has since claimed this topic" and skips the stale leave().
|
|
*/
|
|
const topicGeneration = new Map<string, number>();
|
|
|
|
/**
|
|
* Opens a topic for full conversation view: fetches a page of history and wires live updates.
|
|
* Uses withData(undefined, undefined, limit), NOT withLaterData(limit) -- if prefetchPreview already
|
|
* nudged the topic's local _maxSeq up to just that one preview message, withLaterData would ask for
|
|
* "newer than that" and the server would correctly report back empty.
|
|
*
|
|
* Known gap: for a brand-new P2P topic the peer has never messaged, the old app defers subscribing
|
|
* at all until the user's first send (avoiding server-side subscription state for chats opened but
|
|
* never used) -- not yet replicated here since the new-conversation picker flow doesn't exist yet.
|
|
*/
|
|
export function openConversation(topicName: string): Promise<Topic> {
|
|
topicGeneration.set(topicName, (topicGeneration.get(topicName) || 0) + 1);
|
|
const existing = inFlightSubscribe.get(topicName);
|
|
if (existing) return existing;
|
|
const promise = (async () => {
|
|
// Let any in-flight chat-list preview subscribe for this same topic settle first, rather than
|
|
// firing a second overlapping `{sub}` packet at it (see inFlightPreview above).
|
|
const previewPending = inFlightPreview.get(topicName);
|
|
if (previewPending) await previewPending.catch(() => {});
|
|
const topic = getTinode().getTopic(topicName);
|
|
wireTopicCallbacks(topic);
|
|
if (topic.isSubscribed()) {
|
|
await topic.leave(false);
|
|
}
|
|
const query = topic.startMetaQuery().withLaterDesc().withLaterSub().withAux().withData(undefined, undefined, MESSAGES_PAGE);
|
|
await topic.subscribe(query.build());
|
|
// Opening a conversation via a normal SPA click always means "I've seen everything up to here" --
|
|
// you can only click one while looking at the page. That assumption breaks for a direct reload or
|
|
// deep link straight to a conversation's URL in a tab that's sitting BACKGROUNDED the whole time
|
|
// (confirmed live: reloading tab-1 mid-test while it stayed the non-frontmost tab landed here with
|
|
// the tab genuinely hidden) -- gated on visibility so that case correctly leaves any
|
|
// already-unread history alone for the me.onPres correction above to keep reporting as unread,
|
|
// instead of this seeding call silently absolving it the instant the route mounts.
|
|
if (document.visibilityState === 'visible') {
|
|
markConfirmedRead(topicName, (topic as unknown as Contact).seq || 0);
|
|
}
|
|
return topic;
|
|
})();
|
|
inFlightSubscribe.set(topicName, promise);
|
|
promise.finally(() => {
|
|
if (inFlightSubscribe.get(topicName) === promise) inFlightSubscribe.delete(topicName);
|
|
});
|
|
return promise;
|
|
}
|
|
|
|
/** Soft-leave (detach, not unsubscribe) -- cached messages stay in the SDK's local buffer. Waits out
|
|
* any in-flight openConversation() for this same topic first, so a cleanup that fires before the
|
|
* subscribe it's undoing has even resolved doesn't just silently no-op (see inFlightSubscribe above)
|
|
* -- then, per topicGeneration's comment above, skips the actual leave() if a NEWER openConversation
|
|
* call has since claimed this topic while this one was waiting. */
|
|
export async function closeConversation(topicName: string): Promise<void> {
|
|
const myGeneration = topicGeneration.get(topicName) || 0;
|
|
const pending = inFlightSubscribe.get(topicName);
|
|
if (pending) await pending.catch(() => {});
|
|
if (topicGeneration.get(topicName) !== myGeneration) return;
|
|
await getTinode().getTopic(topicName).leave(false).catch(() => {});
|
|
}
|
|
|
|
/**
|
|
* Makes sure a topic can be published to right now, without disturbing whichever conversation is
|
|
* actually open. `Topic.publishMessage()` rejects outright unless `_attached` is true, and that's
|
|
* only reliably the case for the ONE topic openConversation/closeConversation currently has open --
|
|
* any OTHER topic you've ever actually opened and then navigated away from goes back to detached and
|
|
* STAYS that way (closeConversation's leave() doesn't restore prefetchPreview's original one-shot
|
|
* subscription, and prefetchPreview itself no-ops on a topic it's already touched once, attached or
|
|
* not). That covers forwarding a message to anyone other than the person/group you're currently
|
|
* chatting with -- i.e. most real forwards -- so this isn't a rare edge case to special-case around,
|
|
* it's the common one. Reuses `inFlightSubscribe` so a concurrent openConversation() for the same
|
|
* topic is awaited/shared rather than racing it with a second `{sub}` packet (see openConversation's
|
|
* own comment above for why that matters). Deliberately left attached afterward rather than re-left --
|
|
* same "cheap to leave attached, likely reopened soon anyway" call prefetchPreview already makes.
|
|
*/
|
|
export function ensureTopicAttached(topicName: string): Promise<Topic> {
|
|
const topic = getTinode().getTopic(topicName);
|
|
const pending = inFlightSubscribe.get(topicName);
|
|
if (pending) return pending;
|
|
if (topic.isSubscribed()) return Promise.resolve(topic);
|
|
wireTopicCallbacks(topic);
|
|
const promise = topic.subscribe().then(() => topic);
|
|
inFlightSubscribe.set(topicName, promise);
|
|
promise.finally(() => {
|
|
if (inFlightSubscribe.get(topicName) === promise) inFlightSubscribe.delete(topicName);
|
|
});
|
|
return promise;
|
|
}
|
|
|
|
let chatListSnapshot: Contact[] | null = null;
|
|
|
|
/**
|
|
* Real, addressable chat-list topic types this backend actually issues -- deliberately NOT using
|
|
* `Topic#isCommType()`/`isP2PType()` (confirmed live by reading tinode-sdk's own `Topic.topicType()`
|
|
* table: it maps prefix `'usr'` to P2P, with NO entry for `'p2p'` at all). That table is right for a
|
|
* peer ALIAS (`usr<peerId>`, used before a P2P topic has ever been subscribed), but this backend's
|
|
* REAL, server-assigned P2P topic name is `p2p<hash>` (confirmed via raw `{meta topic:"me"}` capture:
|
|
* every subscription the server reports uses this form, never the alias) -- so `isCommType()` returns
|
|
* false for every P2P topic once its real name is known, silently filtering ALL of them out of
|
|
* `MeTopic.contacts()`. This has nothing to do with account age or how a conversation was opened --
|
|
* verified by direct fresh-login inspection that even a heavily-used account with many real, working
|
|
* P2P friendships had ZERO P2P entries in `contacts()`; every P2P row the chat list has ever shown
|
|
* this session was actually the special-cased `slf` self-chat entry.
|
|
*/
|
|
function isChatListTopicName(name: string): boolean {
|
|
return name.startsWith('p2p') || name.startsWith('grp') || name === 'slf';
|
|
}
|
|
|
|
/**
|
|
* Cached the same way getMessagesSnapshot is, but invalidated by ANY topic's change (a new message
|
|
* on a contact that isn't currently open still needs to move that row and refresh its preview).
|
|
* Triggers each contact's one-shot preview prefetch as a side effect of being read -- cheap and
|
|
* idempotent (prefetchPreview no-ops after the first call per topic), so it's fine to do this on
|
|
* every rebuild rather than needing a separate "wire up previews" pass.
|
|
*
|
|
* Uses `Tinode#mapTopics` (every locally-cached topic, unfiltered) + `isChatListTopicName` instead of
|
|
* `MeTopic#contacts()` -- see that function's own comment for why `contacts()`'s built-in filter can't
|
|
* be trusted here. `mapTopics` still only sees topics the SDK has locally cached, which `me`'s own
|
|
* subscribe (`subscribeMeTopic`'s `withLaterSub()`) and any direct `openConversation()` both populate.
|
|
*/
|
|
export function getChatListSnapshot(): Contact[] {
|
|
if (chatListSnapshot) {
|
|
chatListSnapshot.forEach(repairContactReadState);
|
|
return chatListSnapshot;
|
|
}
|
|
const byTopic = new Map<string, Contact>();
|
|
getTinode().mapTopics((topic) => {
|
|
if (!topic.name || !isChatListTopicName(topic.name) || goneTopicNames.has(topic.name)) return;
|
|
prefetchPreview(topic.name);
|
|
// `.topic` (what every consumer of this list actually reads) normally arrives via
|
|
// `_processMetaSubs` merging the server's own `sub.topic` field onto this same cached instance --
|
|
// but a brand-new P2P topic reached through `openConversation()` is cached here the moment its
|
|
// OWN subscribe resolves, potentially before `me`'s subscription list has ever reported it. Set
|
|
// explicitly rather than assuming that merge already happened; kept as the same live instance
|
|
// (not a clone) so prototype methods like `latestMessage()` survive.
|
|
const contact = topic as unknown as Contact;
|
|
contact.topic = topic.name;
|
|
repairContactReadState(contact);
|
|
byTopic.set(topic.name, contact);
|
|
});
|
|
const rows = [...byTopic.values()];
|
|
chatListSnapshot = rows;
|
|
return rows;
|
|
}
|
|
|
|
function invalidateChatListSnapshot() {
|
|
chatListSnapshot = null;
|
|
}
|
|
anyTopicListeners.add(invalidateChatListSnapshot);
|
|
|
|
/**
|
|
* Re-fires the `me` topic subscribe and every contact's preview subscribe once a WS reconnect has
|
|
* successfully re-authenticated (connection.ts's onReauthenticated). Bypasses subscribeMeTopic's/
|
|
* prefetchPreview's own "already done" guards on purpose -- those guards exist to stop a second
|
|
* *concurrent* call from firing a redundant `{sub}` while one is already in flight, not to reflect
|
|
* whether the topic is still genuinely attached, and after any disconnect it never is (the SDK
|
|
* resets `_attached` on every cached topic, confirmed by reading tinode.dev.js's #disconnected()).
|
|
* `Topic.subscribe()` itself only short-circuits when `_attached` is still true, so calling it again
|
|
* here for an already-detached topic genuinely resends `{sub}`, not a silent no-op.
|
|
*
|
|
* Deliberately scoped to topics this module already knows about (the `me` topic + everything
|
|
* prefetchPreview has ever touched) rather than tracking "the one conversation currently open" as
|
|
* separate state -- in practice the chat list and an open conversation are mounted together in this
|
|
* app's layout, so the open topic's contact row has already gone through prefetchPreview by the time
|
|
* anyone could be looking at it. A conversation reached by a deep link that never rendered the chat
|
|
* list at all is the one case this doesn't cover; also out of scope: backfilling any messages that
|
|
* were sent by the peer during the drop itself -- this only resumes *live* updates going forward,
|
|
* it doesn't gap-fill what was missed while disconnected.
|
|
*/
|
|
onReauthenticated(() => {
|
|
const me = getTinode().getMeTopic();
|
|
wireTopicCallbacks(me);
|
|
me.onContactUpdate = () => notifyTopic(me.name);
|
|
me.subscribe(me.startMetaQuery().withLaterSub().withDesc().withTags().withCred().build()).catch(() => {});
|
|
for (const topicName of previewPrefetched) {
|
|
const topic = getTinode().getTopic(topicName);
|
|
wireTopicCallbacks(topic);
|
|
topic.subscribe(topic.startMetaQuery().withLaterData(1).build()).catch(() => {});
|
|
}
|
|
});
|
|
|
|
/**
|
|
* Real, reproduced bug (2026-09-25 review): every module-level cache below is scoped by topic NAME,
|
|
* not by account -- and topic names collide across accounts by construction, not edge case (`'slf'`
|
|
* is the literal self-chat topic name for every account, `isChatListTopicName` below). Without this,
|
|
* logging out and into a DIFFERENT account in the same tab (no full reload -- resetTinode() itself
|
|
* never reloads the page) carries the previous account's cached state forward: `confirmedReadSeq`
|
|
* specifically was confirmed to silently mark the new account's genuinely-unread 'slf' messages as
|
|
* read the next time reconcileMeSubs() ticked, since it read the OLD account's higher confirmed seq
|
|
* as a floor for the new account's much-lower real one. Same reasoning extends to every other cache
|
|
* here: none of them should outlive the session that populated them.
|
|
*/
|
|
onTinodeReset(() => {
|
|
confirmedReadSeq.clear();
|
|
previewPrefetched.clear();
|
|
messageSnapshots.clear();
|
|
goneTopicNames.clear();
|
|
chatListSnapshot = null;
|
|
});
|
|
|
|
const ME_RECONCILE_INTERVAL_MS = 30_000;
|
|
let meReconcileTimer: ReturnType<typeof setInterval> | null = null;
|
|
|
|
/**
|
|
* Best-effort mitigation for a real backend gap that no amount of frontend-only code can fully close:
|
|
* confirmed by reading im_be's server/im_group_events.go, EVERY group lifecycle event (created, member
|
|
* added/removed, dissolved, owner transferred, ...) goes through publishIMGroupRealtimeEvent, which
|
|
* only reaches sessions ALREADY subscribed to that specific group topic. Unlike P2P -- which has a
|
|
* dedicated force-delivery path straight to a peer's session regardless of subscription state
|
|
* (deliverIMConversationSystemMessageToP2PSessions) -- groups have no equivalent, so a member who has
|
|
* never opened a given group gets zero live signal when added to it: no chat-list row, no unread badge,
|
|
* nothing, indefinitely, until something re-syncs. Confirmed live (2026-09-16): a brand-new group with a
|
|
* genuinely passive, fully-connected, already-on-/messages member produced no change at all, even
|
|
* several seconds after a real message was sent into it.
|
|
*
|
|
* There is nothing to subscribe to or react to for a topic this client doesn't know exists yet, so the
|
|
* only thing a client can do is periodically ask "what's new" -- reusing the exact same incremental
|
|
* `withLaterSub()` semantics subscribeMeTopic()/onReauthenticated() above already rely on, just issued
|
|
* via `getMeta()` instead of `subscribe()`. `Topic.subscribe()` short-circuits once `_attached` is
|
|
* already true (the normal, undisturbed state this is guarding, unlike the reconnect case above), but
|
|
* `getMeta()` sends the `{get}` regardless of attach state -- the same distinction ConversationView's
|
|
* own P2P desc/presence fix relies on.
|
|
*/
|
|
function reconcileMeSubs() {
|
|
const me = getTinode().getMeTopic();
|
|
if (!me.isSubscribed()) return;
|
|
// Snapshot every currently-known topic's read-state fields before the fetch -- see the .then()
|
|
// below for why the response can't be trusted at face value for topics already tracked (only for
|
|
// genuinely new ones, which is this mitigation's entire reason to exist).
|
|
const before = new Map<string, { seq: number; read: number; recv: number; unread: number }>();
|
|
for (const c of getChatListSnapshot()) {
|
|
if (c.topic) before.set(c.topic, { seq: c.seq || 0, read: c.read || 0, recv: c.recv || 0, unread: c.unread || 0 });
|
|
}
|
|
me.getMeta(me.startMetaQuery().withLaterSub().build())
|
|
.then(() => {
|
|
// Real, live-confirmed bug (2026-09-16, reported directly): tinode-sdk's own merge utility
|
|
// (mergeObj in utils.js) has a defensive "keep the later value" rule for Date fields but NONE
|
|
// for plain numbers -- seq/read/recv/unread just get blindly overwritten by whatever this
|
|
// fetch's response says, confirmed by reading the source. If the server's view of a sub's read
|
|
// cursor is even momentarily behind a `{note read}` the client already sent (e.g. this timer or
|
|
// a focus/visibility trigger firing shortly after the user opened and read a conversation), this
|
|
// silently un-reads it: the badge reappears with no new message behind it, and re-focusing the
|
|
// window doesn't clear it either since nothing about it actually changed to re-trigger a fresh
|
|
// read-mark -- confirmed reproducing exactly like this live, not a hypothetical race. Since plain
|
|
// numbers can't defend themselves the way Dates do, restore anything that regressed for topics
|
|
// already known BEFORE this fetch started, rather than trust the fetch there -- this mitigation
|
|
// only needs to win for topics that were unknown before it (the actual gap it exists to close),
|
|
// not overwrite ones a user has already read in the meantime.
|
|
for (const c of getChatListSnapshot()) {
|
|
if (!c.topic) continue;
|
|
const prev = before.get(c.topic);
|
|
if (!prev) {
|
|
// Brand-new topic to this session -- exactly what this mitigation is for. A fresh member's
|
|
// sub record can legitimately come back "already caught up" (read === seq) from the
|
|
// server's own default, which would otherwise leave being newly added to a group producing
|
|
// NO unread signal at all whenever it happens to have zero messages so far -- real,
|
|
// reported UX gap ("被拉入群时title的消息没有提示"): the tab-title/favicon-badge (see lib/
|
|
// notifications/tabIndicator.ts) are driven by this same unread count, so nothing tells the
|
|
// user anything happened. Force it to read as genuinely unread from this client's own
|
|
// perspective regardless of what the server defaulted it to.
|
|
c.read = 0;
|
|
c.unread = c.seq || 0;
|
|
notifyTopic(c.topic);
|
|
if (c.topic.startsWith('grp')) newGroupListeners.forEach((cb) => cb(c.topic!));
|
|
continue;
|
|
}
|
|
const seq = c.seq || 0;
|
|
const unread = c.unread || 0;
|
|
if (seq <= prev.seq && unread > prev.unread) {
|
|
c.read = prev.read;
|
|
c.recv = prev.recv;
|
|
c.unread = prev.unread;
|
|
notifyTopic(c.topic);
|
|
}
|
|
// Separate, real bug this same guard doesn't cover (live-confirmed 2026-09-24, reported
|
|
// directly): sending your OWN message into a topic that's already open bumps `confirmedReadSeq`
|
|
// synchronously (ConversationView's noteRead effect), long before the async `{note read}` this
|
|
// relies on has actually reached the server. A `{get}` already in flight since before that
|
|
// moment can come back with a real, ADVANCED `seq` (the new message the server just accepted)
|
|
// paired with a `read` that hasn't caught up server-side yet -- `seq <= prev.seq` above is
|
|
// false (seq genuinely changed), so that guard correctly doesn't fire, and this spurious
|
|
// `unread:1` gets applied verbatim even though the user is the one who just sent it. Clamp
|
|
// `read` to what THIS client already knows it has confirmed seeing, regardless of what the
|
|
// fetch says -- a floor, never pushes `read` past the server's own value when the server is
|
|
// genuinely ahead of this record (e.g. read from a different, already-synced device).
|
|
const confirmed = getConfirmedRead(c.topic);
|
|
if (confirmed > (c.read || 0)) {
|
|
c.read = confirmed;
|
|
if ((c.recv || 0) < confirmed) c.recv = confirmed;
|
|
c.unread = Math.max(0, (c.seq || 0) - confirmed);
|
|
notifyTopic(c.topic);
|
|
}
|
|
}
|
|
})
|
|
.catch(() => {});
|
|
}
|
|
|
|
/**
|
|
* Starts the periodic timer plus tab-focus/visibility triggers (the common "switched away and came
|
|
* back" case gets an immediate catch-up instead of waiting for the next tick). Call once per
|
|
* authenticated session (RequireAuth.tsx) and invoke the returned function on logout/unmount -- safe
|
|
* to start/stop repeatedly (React 19 StrictMode's mount->cleanup->remount included), unlike
|
|
* subscribeMeTopic() itself, which is guarded separately against being re-fired.
|
|
*/
|
|
export function startMeReconciliation(): () => void {
|
|
meReconcileTimer = setInterval(reconcileMeSubs, ME_RECONCILE_INTERVAL_MS);
|
|
const onVisible = () => {
|
|
if (document.visibilityState === 'visible') reconcileMeSubs();
|
|
};
|
|
document.addEventListener('visibilitychange', onVisible);
|
|
window.addEventListener('focus', reconcileMeSubs);
|
|
return () => {
|
|
if (meReconcileTimer) clearInterval(meReconcileTimer);
|
|
meReconcileTimer = null;
|
|
document.removeEventListener('visibilitychange', onVisible);
|
|
window.removeEventListener('focus', reconcileMeSubs);
|
|
};
|
|
}
|