fix(desktop): prefer cloud-confirmed v2 project in v1→v2 workspace adopt#4137
Conversation
When multiple host.db rows share a repo_path, the importer's repoPath→v2id map was last-write-wins, so an orphan local project (e.g. left over from a manual repair) could shadow the canonical id. Workspace adopt then called v2Workspace.create with the orphan id and tripped the org-scope check with "Project not found in this organization". Prefer ids that appear as a projectId on the org's cloud workspace list, falling back to first-seen.
Greptile SummaryThis PR fixes a "Project not found in this organization" error during v1→v2 workspace adopt that occurred when
Confidence Score: 4/5The fix is correct for the described duplicate-row scenario, but the cloud query being excluded from the loading gate means a user with slow network could still trigger the exact error being fixed. The deduplication logic is sound and handles the orphan-vs-canonical case correctly once all data is available. The one gap is that apps/desktop/src/renderer/routes/_authenticated/components/V1ImportModal/ImportWorkspacesPage/ImportWorkspacesPage.tsx — specifically the
|
| Filename | Overview |
|---|---|
| apps/desktop/src/renderer/routes/_authenticated/components/V1ImportModal/ImportWorkspacesPage/ImportWorkspacesPage.tsx | Adds cloud-workspace-backed project ID preference when deduplicating duplicate repo_path rows; cloudWorkspacesQuery.isPending is still excluded from the isLoading gate. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[hostProjectListQuery.data] --> B{Iterate v2 projects}
C[cloudWorkspacesQuery.data] --> D[Build projectIdsInCloud Set]
D --> B
B --> E{existing entry for repoPath?}
E -- No --> F[Set first-seen id]
E -- Yes --> G{new id in cloud AND existing NOT in cloud?}
G -- Yes --> H[Replace with cloud-backed id]
G -- No --> I[Keep existing id]
F --> J[v2ByPath map]
H --> J
I --> J
J --> K[Map v1 project id → v2 project id]
K --> L[Adopt workspace via v2Workspace.create]
Comments Outside Diff (1)
-
apps/desktop/src/renderer/routes/_authenticated/components/V1ImportModal/ImportWorkspacesPage/ImportWorkspacesPage.tsx, line 120-125 (link)cloudWorkspacesQuery.isPendingis absent from theisLoadinggate. The new deduplication inv2ProjectIdByV1Iddepends oncloudWorkspacesQuery.data, so ifhostProjectListQuerysettles first, the loading spinner disappears whileprojectIdsInCloudis still empty — the orphan row wins, the correct project ID is not yet picked, and a user who clicks Adopt in that window hits the same "Project not found" error the fix was meant to cure.Prompt To Fix With AI
This is a comment left during a code review. Path: apps/desktop/src/renderer/routes/_authenticated/components/V1ImportModal/ImportWorkspacesPage/ImportWorkspacesPage.tsx Line: 120-125 Comment: `cloudWorkspacesQuery.isPending` is absent from the `isLoading` gate. The new deduplication in `v2ProjectIdByV1Id` depends on `cloudWorkspacesQuery.data`, so if `hostProjectListQuery` settles first, the loading spinner disappears while `projectIdsInCloud` is still empty — the orphan row wins, the correct project ID is not yet picked, and a user who clicks Adopt in that window hits the same "Project not found" error the fix was meant to cure. How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
apps/desktop/src/renderer/routes/_authenticated/components/V1ImportModal/ImportWorkspacesPage/ImportWorkspacesPage.tsx:120-125
`cloudWorkspacesQuery.isPending` is absent from the `isLoading` gate. The new deduplication in `v2ProjectIdByV1Id` depends on `cloudWorkspacesQuery.data`, so if `hostProjectListQuery` settles first, the loading spinner disappears while `projectIdsInCloud` is still empty — the orphan row wins, the correct project ID is not yet picked, and a user who clicks Adopt in that window hits the same "Project not found" error the fix was meant to cure.
```suggestion
const isLoading =
projectsQuery.isPending ||
workspacesQuery.isPending ||
worktreesQuery.isPending ||
hostProjectListQuery.isPending ||
cloudWorkspacesQuery.isPending ||
worktreeListQueries.some((q) => q.isPending);
```
Reviews (1): Last reviewed commit: "fix(desktop): prefer cloud-confirmed v2 ..." | Re-trigger Greptile
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe v2 project mapping logic in the import workspace page is refactored to prefer v2 IDs already present in cloud workspaces when duplicate repo paths exist. The memo dependency array and loading state are updated to account for cloud workspace query status. ChangesV1 to V2 Project Mapping with Cloud Workspace Preference
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
cloudWorkspacesQuery was missing from isLoading, so a slow cloud response let the modal render Adopt buttons before the preference logic had the signal it needs to skip orphan host.db rows. The preference would then fall back to first-seen and could still pick the orphan, hitting the exact error this PR is meant to prevent.
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
…opt (superset-sh#4137) * fix(desktop): prefer cloud-confirmed v2 project in v1→v2 workspace adopt When multiple host.db rows share a repo_path, the importer's repoPath→v2id map was last-write-wins, so an orphan local project (e.g. left over from a manual repair) could shadow the canonical id. Workspace adopt then called v2Workspace.create with the orphan id and tripped the org-scope check with "Project not found in this organization". Prefer ids that appear as a projectId on the org's cloud workspace list, falling back to first-seen. * fix(desktop): gate v1 import modal on cloud workspace list cloudWorkspacesQuery was missing from isLoading, so a slow cloud response let the modal render Adopt buttons before the preference logic had the signal it needs to skip orphan host.db rows. The preference would then fall back to first-seen and could still pick the orphan, hitting the exact error this PR is meant to prevent.
1 participant
Summary
host.dbhas twoprojectsrows sharing the samerepo_path.ImportWorkspacesPagebuilds itsrepoPath → v2 idmap with last-write-winsMap.set, so an orphan local row (e.g. left over from a manual repair where the cloud counterpart got hard-deleted) can shadow the canonical id. Adopt then forwards the orphan tov2Workspace.create, which can't find it under the user's org.projectIdonworkspace.cloudList— that's a cheap proxy for "actually exists in cloud" sincev2_workspacesFK tov2_projects. Falls back to first-seen when no candidate has cloud workspaces, so the common single-row case is unchanged.1c99c8eb…(canonical, 26 cloud workspaces) and07682010…(orphan, no cloud row) both pointing at/Users/satyapatel/code/superset. Pre-fix: every Adopt button errored with the org-scope message. Post-fix: importer resolves to1c99c8eb…and Adopt succeeds.Test plan
projectsrow (one cloud-backed, one orphan) sharing arepo_path, open the V1 import modal → "Bring over your workspaces" → Adopt completes for every row.Summary by cubic
Fixes v1→v2 workspace adopt failures by preferring the cloud-backed v2 project when multiple host
projectsrows share the same repo path. Prevents "Project not found in this organization" errors during Adopt.repoPath, choose the id that appears as aprojectIdin the cloud workspace list; otherwise keep the first seen.cloudWorkspacesQueryloading and includecloudWorkspacesQuery.datain the memo deps so the mapping updates once cloud data arrives.Written for commit 24adbb5. Summary will update on new commits.
Summary by CodeRabbit