[Bug]: Timeline jumps far up right after sending in a long thread#13706

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

In the app it is timing dependent. It shows up most in long threads with long replies, especially on desktop with a busy main thread:

1. Open a thread with a lot of history and long assistant replies, scrolled to the bottom.
2. Send a message.
3. About half a second later the timeline jumps far up, often near the top of the loaded history, and stays there.

A small page that renders only a LegendList (no T3 Code components or data), served by the apps/web dev server, reproduces it every time:

1. Render a LegendList with 150 rows of about 900px each, estimatedItemSize={90}, initialScrollAtEnd, and maintainVisibleContentPosition={{ data: true, size: true }} (the timeline's options).
2. Scroll up a few screens.
3. Call listRef.current.scrollToEnd({ animated: true }).
4. While that scroll is running, remove the last row from data.

Expected behavior

The list ends at the end, with 149 rows.

Actual behavior

The list lands on rows 0 and 1, about 25,000px from the end. The same steps without step 4 end at the end. Removing the last row without a scroll in flight keeps the position.

The same page reproduces in a separate plain app with pristine npm @legendapp/list 3.3.5, when built with Rolldown-based Vite (apps/web builds with Rolldown through vite-plus). With esbuild-based Vite it does not jump. Under the same Rolldown setup, 3.4.0 does not jump either.

Impact

Major degradation or frequent failure

Version or commit

main @ ed809f7ad2 (@legendapp/list 3.3.5 with T3 Code's patch). @legendapp/list 3.4.0 does not reproduce. Its changelog lists "End-following and animated programmatic scrolling now stay aligned through footer, viewport, and native layout changes."

Environment

Windows 11, desktop nightly and web client from vp run dev. Provider independent. The same code is in the React Native build that mobile uses.

Logs or stack traces

No errors. Reading listRef.current.getState() every frame during a jump in a long thread:

The element's scrollTop stayed about where it was the whole time; only LegendList's state reset. The row data never went empty. A totalSize listener caught the collapse. Its stack runs through checkResetContainers, calculateItemsInView, the MVCP check, getItemSize, setSize, and addTotalSize.

Screenshots, recordings, or supporting files

The standalone repro, unpatched:

https://github.com/user-attachments/assets/22c266c7-1763-42e4-ae23-851b2de6cc01

Workaround

Press End or use "Scroll to end".

Cause

scrollToEnd records the last index as state.scrollingTo. When data shrinks before that scroll completes, the MVCP check in prepareMVCP resolves the target with getId(state, scrollTarget). That index is now past the end of data, so it returns null. The check still sizes it:

getItemSize passes the null key to setSize, and addTotalSize treats a null key as "set the total to this value". The total height collapses to one estimated row. That sends the list to scroll = 0 and it re-lays out unmeasured rows at the average measured row height. In a thread of long replies that average is several times the 90px estimate, so the old offset now lands near the top.

In T3 Code the shrink comes from the timeline's trailing rows. When a turn starts, the live activity row at the end is replaced, which briefly removes one row while the send's scrollToEnd is still in flight. A busy main thread widens that window. The desktop running-thread keep-alive and very large environments made it frequent here, but neither is required.

Skipping that size check when targetId is null fixes the repro. I'll open a PR that adds the guard to patches/@legendapp__list@3.3.5.patch.