fix(client-runtime): branch list no longer resets while paging through refs by a20hek · Pull Request #5845 · pingdotgg/t3code

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

a20hek · 2026-08-09T15:35:59Z

What Changed

listRefs in createVcsEnvironmentAtoms was one Atom.family nested inside another. It is now a single family keyed by JSON.stringify([environmentId, input]), the same pattern createEnvironmentRpcQueryAtomFamily uses.

Why

The cached ref pages live in an Atom.family, and it was a family nested inside another family. A family only holds its entries weakly, and nothing held on to the inner one between lookups. So at any random moment the garbage collector could throw the whole cache away. When that happened mid-scroll, every page the picker had loaded was just gone: the list went empty, the scroll jumped to the top, and fetching started over from page 1. That's the reset in the video on the issue.

With one flat family, the pages that are in use keep their cache entries alive, so GC can't wipe them and the scroll stays put. This also fixes in-use ref lists refetching at random, which #4727 tried to stop.

Before:
https://github.com/user-attachments/assets/79ba896d-3f06-4092-ad46-3311380e7499

After:
https://github.com/user-attachments/assets/2714e07e-e10f-47c1-b940-af05dc6fa2fd

Atom.family holds its entries via WeakRef, so nesting one family inside another leaves the inner family (and its whole atom cache) with no strong referent between lookups. Whenever GC ran between two listRefs calls, every cached page atom was recreated valueless: the branch picker's data transiently became empty, the browser clamped scrollTop to 0, and all pages refetched from page 1 - a scroll reset at a random page boundary. Flatten listRefs to a single-level family keyed by [environmentId, input], matching the environmentRpcKey pattern used by the other query families. Callers hold the page atoms strongly, so the cache now survives GC for as long as the atoms are in use. Verified by scripted browser runs sampling scrollTop/scrollHeight every frame while paging through 811 refs: before the fix the list collapsed on 2 of 3 runs; after, 3 runs x 8 page-appends under forced GC pressure held position every time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

coderabbitai · 2026-08-09T15:36:09Z

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 Plus

Run ID: fb2cdf58-fde5-4a25-91bf-1462a5577661

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-08-09T15:40:10Z

Approvability

Verdict: Approved b6a2e23

Straightforward bug fix that flattens a nested Atom.family to prevent inner atoms from being garbage-collected prematurely during pagination. The change is well-documented with a comment explaining the root cause, and the core caching logic remains unchanged.

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

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

a20hek closed this Aug 9, 2026

a20hek deleted the fix/vcs-listrefs-nested-weak-family branch August 9, 2026 15:38