Use latest user message time for thread timestamps

[juliusmarminge]

Summary

• Update sidebar and command palette timestamps to prefer latestUserMessageAt so threads reflect the most recent user activity.
• Tighten store equality checks for thread sessions and latest turns to avoid unnecessary summary churn.
• Remove redundant sidebar summary writes when the derived thread summary has not changed.

Testing

• Not run (PR description only).
• Relevant checks from the project should pass: bun fmt, bun lint, bun typecheck, and bun run test.

---

Note

Medium Risk
Moderate risk because it refactors store update paths and equality checks for thread shell/session/turn state, which could affect re-render behavior and sidebar consistency across shell vs detail streams.

Overview
Thread timestamps in the sidebar and command palette now prefer latestUserMessageAt (falling back to updatedAt/createdAt) so recency reflects user activity.

Sidebar context-menu actions (multi-select and per-thread) now read thread data via a useRef-backed map to avoid stale captures and reduce memo invalidation.

Store/state updates are tightened: sidebarThreadSummaryById is now shell-stream-only (detail writes removed), syncServerReadModel is removed, and new structural equality helpers for sessions/turns reduce redundant state churn. formatRelativeTime also treats anything under 60s as "just now".

^{Reviewed by Cursor Bugbot for commit c26d203. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Use latest user message time for thread timestamps in sidebar and command palette

• Thread timestamps in the sidebar and command palette now show latestUserMessageAt when available, falling back to updatedAt then createdAt.
• Relative timestamps under 60 seconds now display as "just now" instead of showing a seconds count.
• Removes syncServerReadModel from the app store; sidebar summaries are now written exclusively by the shell stream, with deep structural equality checks reducing unnecessary state updates.
• Stale closure bugs in archiveThread and sidebar context menu actions are fixed using refs to hold the latest function/map values.

^{Macroscope summarized c26d203.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 39b2e5e0-7603-427c-8e02-516dd7efcb11

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/fix-sidebar-timestamp

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Sidebar summary never written for full thread updates
  • Restored the removed block in writeThreadState that builds a SidebarThreadSummary via buildSidebarThreadSummary and conditionally writes it to sidebarThreadSummaryById when the derived summary has changed.

Or push these changes by commenting:

@cursor push b8d786d2fc

Preview (b8d786d2fc)

diff --git a/apps/web/src/store.ts b/apps/web/src/store.ts
--- a/apps/web/src/store.ts
+++ b/apps/web/src/store.ts
@@ -519,6 +519,8 @@
   const nextTurnState = toThreadTurnState(nextThread);
   const previousShell = state.threadShellById[nextThread.id];
   const previousTurnState = state.threadTurnStateById[nextThread.id];
+  const previousSummary = state.sidebarThreadSummaryById[nextThread.id];
+  const nextSummary = buildSidebarThreadSummary(nextThread);
 
   let nextState = state;
 
@@ -652,6 +654,16 @@
     };
   }
 
+  if (!sidebarThreadSummariesEqual(previousSummary, nextSummary)) {
+    nextState = {
+      ...nextState,
+      sidebarThreadSummaryById: {
+        ...nextState.sidebarThreadSummaryById,
+        [nextThread.id]: nextSummary,
+      },
+    };
+  }
+
   return nextState;
 }
 
@@ -718,7 +730,9 @@
     };
   }
 
-  if (!threadSessionsEqual(state.threadSessionById[nextThread.shell.id] ?? null, nextThread.session)) {
+  if (
+    !threadSessionsEqual(state.threadSessionById[nextThread.shell.id] ?? null, nextThread.session)
+  ) {
     nextState = {
       ...nextState,
       threadSessionById: {

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit 0bb7044. Configure here.}

[cursor]

Sidebar summary never written for full thread updates

High Severity

The writeThreadState function no longer writes to sidebarThreadSummaryById, but it's the sole write path for many thread events. When a thread.created event fires, the thread ID is added to threadIds and other structures, but no sidebarThreadSummaryById entry is created. Since selectSidebarThreadsForProjectRef filters out threads without a sidebar summary entry, newly created threads won't appear in the sidebar until a separate thread-upserted shell event arrives. Similarly, all event-driven updates (thread.message-sent, thread.archived, session-set, etc.) via updateThreadState → writeThreadState won't update the sidebar's latestUserMessageAt, hasPendingApprovals, or other derived fields — the very fields this PR aims to leverage.

Additional Locations (1)

• apps/web/src/store.ts#L1382-L1383

 

^{Reviewed by Cursor Bugbot for commit 0bb7044. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR combines a minor timestamp display change with a substantial refactor of thread state management in store.ts, including removal of syncServerReadModel and ~300 lines of related tests. An unresolved high-severity review comment identifies that the refactor may cause newly created threads to not appear in the sidebar until a separate shell event arrives, directly impacting the feature this PR aims to implement.

^{You can customize Macroscope's approvability policy. Learn more.}