[sentry-junior]

Like Slack, the dashboard now remembers how far each person has read a Conversation. It opens there and marks the spot with a "New" line.

Screenshots

Desktop	Mobile

Server

• Adds the junior_conversation_read_positions table (migration 0071). It keeps one row per user and Conversation.
• Adds PUT /api/conversations/:id/read-position. The stored value only moves forward (greatest(existing, new)). It is also capped at the last event, so devices can report in any order, and a bad client cannot hide messages that come later.
• The detail response now includes readPosition for the signed-in viewer. Other viewers never see it.

Dashboard

• Rows built from stored events now carry data-transcript-seq. While the page is visible, the transcript reports the last row that reached the viewport, 750 ms after scrolling or layout changes stop. It reports only forward. A hidden tab and search results do not report. Leaving the page or hiding the tab sends the pending report at once.
• When a Conversation opens, the page saves the read position from the first detail. The last unread row comes from the first detail fetched in that visit, so a cached copy cannot hide messages that arrived while the reader was away. Rows that were unread then get a "New" separator (role="separator"). Rows that arrive later get no marker, so a reader who is following live replies does not see one.
• The detail is fetched on each visit. The cached copy shows at once, and the view moves to the marker when the fetch brings it, unless the reader already scrolled.
• By default, the transcript opens at the marker with a little context above it, and "Jump to latest" is shown. If all unread rows fit on screen, it opens at the bottom as before.
• Settings has a new per-browser choice, "Open conversations at": Where I left off or Latest message. The read position itself stays synced on the server.
• A successful report updates the cached detail, so reopening the Conversation in the same session uses the new position.
• Mock reporting stores read positions per process, so local QA works.

Known limits

• If the saved position comes before the first loaded history page, the marker shows at the top of the loaded rows. It moves up when older pages load, and the scroll anchor from fix(dashboard): Hold the reader's place when transcript layout changes #2511 keeps the view steady.
• Other devices get the new position on their next detail fetch. A transcript that is already open keeps the state from when it opened, like Slack.

Validation

• read-position, detail, and archive integration tests: 10 passed.
• Dashboard unit tests: 48 files, 324 tests passed.
• Dashboard e2e (Chromium): full suite 63 passed. conversation-send "hands web and external messages… without gaps" failed once under full-suite load, then passed alone and with --repeat-each 2.
• New mobile e2e: "opens where the reader left off and reports what they read" and "opens at new messages after a cached reopen and keeps a quick exit".
• Typecheck, lint, migration metadata, file length, test architecture, and dashboard style checks pass.
• WebKit/iOS Safari was not tested in the sandbox.

via @BYK.

--

View Session in Sentry

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
junior-docs	Ready	Preview	Nov 2, 2026 10:19pm UTC

[cursor]

Stale Bugbot comment from a previous run.

[github-actions]

4 screenshot changes — 3 changed · 1 added · 0 removed

Review screenshots in Frameshift

Conversation Child Agent Drawer · Desktop Changed

Conversation Child Agent Drawer · Mobile Changed

Settings · Desktop Changed

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Stale Bugbot comment from a previous run.

[BYK]

I see a few optimizations we can have and am not sure are already in this code:

1. On initial conversation loads, we can cap how far into the present we fetch initially based on the known "last read state" and then load piece meal in the background after the initial load/paint. We should also cap how much further back into the past we load and do virtual lists.
2. To track positions we probably should leverage IntersectionObserver instead of relying on scroll events etc.
3. When updating last read position, we should at least check locally that if it is larger than the last value we read from the server before making the request, right?

[sentry-junior]

Replies to the review, in order. The code changes are in da0d25b.

1. Fetch around the read position, background loads, virtual list. Not in this PR. Today the detail returns the latest 500 events, and older pages load only when the reader comes near the top (an IntersectionObserver on a sentinel). Nothing loads further back in the background. To start at the read position, the API needs an "around this seq" page and forward pages. The client then needs a virtual list. Both change the scroll anchoring from fix(dashboard): Hold the reader's place when transcript layout changes #2511, the bottom pinning, and in-page search (it searches only loaded rows). I suggest a separate PR for this, so this one stays a read-position change.
2. IntersectionObserver. Done. The reporter no longer listens to scroll events or measures rows. An IntersectionObserver keeps the set of rows in the viewport, a MutationObserver observes rows as they mount and unmount, and a report sends the highest seq in that set. The 750 ms delay, forward-only rule, pause for search, and send on leave or hide are the same.
3. Check locally before the request. Done. The reporter already skipped seqs at or before the value at open and its own last report. useMarkConversationRead now also reads the cached detail's readPosition (from polls and other devices) and does not send a seq at or before it. The server greatest() stays, because two devices can still race.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

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

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

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