web/hooks/use-windowed-messages.ts, line 54-56 (link)

Pagination cursor points to summary timestamp instead of first conversation message

When the oldest item in the timeline is a leading activity_summary (activities that predate the first conversation message), msgs[0].timestamp is the synthetic summary timestamp — MAX(activity.created_at) — which is earlier than the first real conversation message. When the user triggers "load older", before = that_timestamp is sent to the server, which finds zero conversation messages before it and falls into the len(rows) == 0 path. That path returns a new summary counting activities with created_at < max_activity, i.e., all but the last activity in the range. The client then prepends this near-duplicate summary (with count - 1), leaving the user with two conflicting leading summaries and hasOlder immediately set back to false.

A related issue on the same block: setHasOlder(apiMsgs.length >= PAGE_SIZE) counts interleaved activity_summary items toward the threshold, so conversations with enough summaries trigger hasOlder = true even when all conversation messages fit on a single page — directly enabling the incorrect cursor scenario above. The correct signal is whether the number of conversation messages returned equaled the requested limit.