fix(web): paginate conversation list + preserve displayOrder (LUM-1618, LUM-1619)

[ashleeradka]

Summary

Two related fixes in apps/web/src/domains/chat/api/conversations.ts and the downstream grouping. Both were silent data-loss / UX bugs flagged by Codex during the migration.

LUM-1618 — paginate the conversation list

fetchConversationList sent a single GET with no limit / offset and ignored the daemon's hasMore signal. The daemon defaults to 50 items per page, so users with more than 50 foreground (or background) conversations silently lost older rows from the sidebar.

Loop over pages with limit=50, accumulating until hasMore is false. A 200-page safety cap (10,000 conversations of one type) and an empty-page guard prevent a malformed hasMore: true response from looping forever.

LUM-1619 — preserve displayOrder for pinned / custom-group buckets

parseConversation dropped the daemon-supplied displayOrder field, and listConversations's global lastMessageAt sort then overrode whatever order the user had drag-set. After a reload, pinned conversations appeared newest-first instead of in the user's custom order.

• Capture displayOrder on Conversation.
• In groupConversations, sort the pinned bucket and each custom-group bucket by displayOrder ascending. Rows missing displayOrder fall back to lastMessageAt newest-first; ties also break on lastMessageAt. The global listConversations sort by recency is preserved so non-bucketed consumers (logs tab, archive page) keep their current behavior.

Closes LUM-1618, LUM-1619.

Test plan

• bun run test:ci — 100 / 100 pass (added new tests for pagination loop / empty-page guard / first-page-exit, displayOrder parsing, and pinned + custom-group displayOrder sort)
• bun run lint — clean (1 preexisting unrelated warning)
• bunx tsc --noEmit — clean

---

Generated by Claude Code

[linear]

LUM-1618

LUM-1619

[vex-assistant-bot]

✦ APPROVE

Value: Two silent data-loss bugs fixed — users with more than 50 conversations no longer get a silently truncated sidebar, and users who drag-reordered their pinned / custom-group conversations no longer see that order scrambled on every reload.

What this does: Adds a paginated fetch loop to fetchConversationList (accumulates pages until hasMore is false), captures displayOrder in parseConversation, and adds a compareByDisplayOrder comparator to sort pinned / custom-group buckets by the server-provided drag order while falling back to lastMessageAt for everything else.

---

Code analysis

Pagination loop (fetchConversationList)

• ApiError thrown on non-OK responses — correct, matches every other function in the file ✅
• Safety cap at 200 pages (10,000 conversations per type) — bounded and documented ✅
• Empty-page guard (if (pageItems.length === 0) break) prevents a malformed hasMore: true from spinning forever ✅
• hasMore defaulted to false when the field is absent or non-boolean ✅
• sessions fallback preserved for backward-compat with older daemon versions ✅

listConversations orchestration

• Promise.allSettled to fetch foreground + background in parallel; background failures degrade gracefully with a Sentry warning and don't break the sidebar ✅
• Dedup by conversationKey (foreground wins on collision) ✅
• Global lastMessageAt sort preserved so non-bucketed consumers (logs tab, archive page) are unaffected ✅

parseConversation — displayOrder field

• Guards typeof === "number" && Number.isFinite(...) — correctly rejects NaN, Infinity, and string "0" ✅
• JSDoc on Conversation.displayOrder is precise and explains which buckets consume it ✅

compareByDisplayOrder comparator

• Ascending by displayOrder, ties break on lastMessageAt newest-first ✅
• Rows with displayOrder win over rows without ✅
• Returns a stable sort for equal timestamps ✅

groupConversations

• Uses slice() before sort on every bucket — never mutates the caller's array ✅
• scheduled and background buckets intentionally left at lastMessageAt order (not drag-reorderable) ✅
• Custom-group sort applied per-bucket in a loop — O(k × n log n) which is fine for realistic sidebar sizes ✅

---

Minor observation (non-blocking)

compareByDisplayOrder: ordered rows win over unordered rows

The comparator puts any row with displayOrder before any row without it. The PR description says "freshly-pinned conversations land near the top until the server assigns them an order" — but the current behavior is the opposite: a freshly-pinned conversation with no displayOrder yet sinks below all drag-reordered ones. This is a transient state (the server should assign displayOrder quickly), but the claim in the description doesn't match the code. If the intended behavior is "new pins appear at the top," the comparator needs to be inverted for the mixed case:

// Current: ordered first, unordered last
if (aOrder != null) return -1;

// Alternative: unordered first (newest pin floats up)
if (aOrder == null) return -1;

Worth confirming intent before the next drag-reorder UX pass.

---

Test coverage

Pagination: three targeted tests — multi-page accumulation (80 items across 2 pages), early exit on hasMore: false, and the empty-page infinite-loop guard. Mock restores in afterEach via client.get = originalGet — correct mock seam (not globalThis.fetch). displayOrder parsing coverage looks solid for the parseConversation layer; I'd add a test in group-conversations.test.ts specifically for the mixed ordered/unordered sort case once the intent above is confirmed.

---

Vellum Constitution — Trust-seeking: silent truncation at 50 conversations and invisible reorder resets are exactly the kind of invisible failure that erodes trust in an app you use every day.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.