Start thread bootstrap as soon as create succeeds - #7
Merged
Conversation
This was referenced Sep 2, 2026
added 2 commits
September 2, 2026 20:19
Create already writes threadQueryKey, then navigates. Bootstrap (GET /threads/:id?include=environment,host, and timeline when the shell asked for it) waited until ThreadDetailView mounted. Prefetch the same query in useCreateThread onSuccess so navigate joins work already in flight.
Phase log records bootstrap-get during useCreateThread onSuccess and requires it to land before mutateAsync returns.
Guitaraholic
force-pushed
the
fix/prefetch-bootstrap-on-create
branch
from
September 2, 2026 19:19
ca973a2 to
725dd71
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
What was wrong
Send waits for
sdk.threads.spawn, seedsthreadQueryKey, then navigates.GET /threads/:id?include=environment,host(and the timeline prefetch AppLayout opts into) started only afterThreadDetailViewmounted. Even with cache paint (Datahazed/bb#6), environment, host, git-diff eligibility, and timeline still paid a round trip after the remount.Related: get-bb/bb#1303. Complements #6 and Datahazed/bb#3 / get-bb/bb#2935.
What changed
loadThreadDetailBootstrap/prefetchThreadDetailBootstrap— the same queryFn the thread view uses.useCreateThreadonSuccess prefetches it, so navigate joins in-flight work instead of starting it after mount.No router change. No
HOST_DAEMON_PROTOCOL_VERSIONbump.Why this way
Create is the last moment we know the thread id before the remount. Starting bootstrap there is cheaper than keeping compose and thread both mounted, and it does not invent
GET /threads/:id/open.The prefetch must use the view’s queryFn. A slimmer prefetch that only does the include GET would cache-hit bootstrap and skip timeline/queue/approvals when #3 is present.
Benefit to bb
Web and desktop, every successful new-thread send that navigates. Environment/host chrome and timeline can be in flight or cached by the time the thread view commits, so first paint is less empty. Daemon protocol unchanged.
Harvest
Independent of #6 (they compose). Open on get-bb after or with #6. #8 stacks on this helper — do not submit #8 first.
Decision record: docs/perf-control-plane.md (PR #9).
How you verified
Phase-order test (
apps/app/src/test/perf-phase.ts) recordsbootstrap-getduringuseCreateThreadonSuccess and requires it to land beforecreate-returned. Starting bootstrap only afterThreadDetailViewmounts fails this test.apps/app/src/hooks/mutations/thread-runtime-mutations.test.tsxasserts the include GET and bootstrap cache before any view mounts. Combined withthread-queries.test.tsx: 35 passed.