fix(components): enable machine picker before doc-meta scan finishes - #498
fix(components): enable machine picker before doc-meta scan finishes#498slashdevcorpse wants to merge 1 commit into
Conversation
Wait on doc-meta or visibility only when no selectable machine exists. Runtime init and local probe still block. Model: grok-4.6
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 427fc944d9
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } | ||
|
|
||
| return isVisibleMachinesLoading && !hasSelectableMachine; | ||
| return (!isDocMetaCacheReady || isVisibleMachinesLoading) && !hasSelectableMachine; |
There was a problem hiding this comment.
Source the early machine outside the scoped visibility gate
On both local and cloud /$workspaceName/chat routes, ChatLanding is under WorkspaceRouteTargetProvider (routes/$workspaceName.tsx:95-102), and its selectableMachines comes from useVisibleMachineMetas, whose enabled flag is supplied by useResolvedWorkspaceScope (use-visible-machine-metas.ts:48-56). That scope remains disabled until docMetaScope.ready (use-resolved-workspace-scope.ts:28-49), which flips true alongside docMetaCacheReady only after the metadata scan (atoms/doc-meta.ts:813-830); while disabled, the visibility hook exposes no machines. Therefore hasSelectableMachine cannot be true during the !isDocMetaCacheReady window, so this new exception is unreachable in the shipped routes and the picker still waits for the full scan. The early selectable state needs to come from a source that is available before this scope-ready gate.
AGENTS.md reference: AGENTS.md:L129-L134
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Leaving this as-is. ChatLanding sits under WorkspaceRouteTargetProvider, and useVisibleMachineMetas is disabled until docMetaScope.ready (resolveWorkspaceDataScope requires that). While disabled the visibility index is empty, so hasSelectableMachine cannot be true in the !isDocMetaCacheReady window. Reading the singleton machine cache before that gate would break the workspace-switch invariant. The Convex visibility fail-open after doc-meta is ready is the path that actually fires. Expanding this PR to a second machine source is out of scope.
|
@slashdevcorpse, this pull request needs updates before review. It is marked If the PR remains invalid for 7 days, it will be closed and marked Policy findings |
Related issue
Closes #496
Refs #317
Problem / pressure
getChatLandingInitialDataLoadingtreats!isDocMetaCacheReadyas always loading, even when a selectable machine already exists. The picker stays disabled through the full metadata scan after local runtime is up.Summary
The gate now matches the visibility fail-open: wait on runtime init and local probe, then wait on doc-meta or visibility only when there is no selectable machine.
useChatLandingDefaultsstill waits on doc-meta for stored agent restore. Does not take #317's mobile sync ladder.Before / after
!isDocMetaCacheReadydisables the picker even with a selectable machine.hasSelectableMachineis false.Test plan
pnpm exec vitest run tests/chat-landing-derived.test.ts— includes the flippedhasSelectableMachine+!isDocMetaCacheReadycase and a still-loading case when no machine exists.Context handoff
Instructions for reviewing agents
getChatLandingInitialDataLoadinginchat-landing-derived.tsand the two tests aroundisDocMetaCacheReady.Authoring context
useOnlineMachineson thismainsnapshot.hasSelectableMachineis true before the scan ends on phone vs desktop.