fix(desktop): use task title as workspace name when opening a task#3678
Conversation
The branch still uses deriveBranchName({slug, title}) so the Linear/GitHub
identifier stays in the branch for traceability; only the displayed
workspace name switches from e.g. "SUPER-172" to the human-readable title.
|
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 (2)
📝 WalkthroughWalkthroughTwo workspace creation calls are modified to use Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~5 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 |
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
Greptile SummaryThis PR updates both task-to-workspace entry points ( Key concerns:
Confidence Score: 3/5Not safe to merge without resolving the workspace deduplication collision — same-title tasks will silently share a workspace. The change is a trivial one-liner in two places and the UX goal is clear, but the workspace deduplication logic keys on Both changed files share the same P1 issue; the backend
|
| Filename | Overview |
|---|---|
| apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/$taskId/components/PropertiesSidebar/components/OpenInWorkspace/OpenInWorkspace.tsx | Single-line change: workspace name switched from task.slug to task.title. Introduces a potential workspace collision for same-title tasks and lacks a fallback for empty titles. |
| apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/components/TasksView/components/TasksTopBar/components/RunInWorkspacePopover/RunInWorkspacePopover.tsx | Single-line change matching OpenInWorkspace. The bulk path amplifies the collision risk: multiple same-title tasks selected together will all map to the same workspace. Progress list still displays task.slug, creating a minor UX inconsistency. |
Sequence Diagram
sequenceDiagram
participant U as User
participant OIW as OpenInWorkspace / RunInWorkspacePopover
participant CW as createWorkspace
participant BE as Backend
U->>OIW: Click "Open in Workspace"
OIW->>OIW: deriveBranchName({slug, title}) → branchName
OIW->>CW: mutateAsyncWithPendingSetup({projectId, name: task.title, branchName})
CW->>BE: Create or find workspace by (projectId + name)
alt name is unique (happy path)
BE-->>CW: {workspace, wasExisting: false}
CW-->>OIW: New workspace created ✓
else same title exists (collision)
BE-->>CW: {workspace, wasExisting: true}
CW-->>OIW: wasExisting=true → agent re-launched in WRONG workspace ✗
end
OIW-->>U: toast success
Comments Outside Diff (1)
-
apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/components/TasksView/components/TasksTopBar/components/RunInWorkspacePopover/RunInWorkspacePopover.tsx, line 369 (link)Batch status list still shows
task.slug, nottask.titleThe progress list during bulk creation still identifies tasks by their slug (line 369:
{task.slug}), while the workspace is now named after their title. This creates a slight UX mismatch — the user sees the slug in the progress list but the workspace opens with the title as its name. Depending on intent, you may want to showtask.titlehere (ortask.title ?? task.slug) so the progress list matches what the user will see in the sidebar.Prompt To Fix With AI
This is a comment left during a code review. Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/components/TasksView/components/TasksTopBar/components/RunInWorkspacePopover/RunInWorkspacePopover.tsx Line: 369 Comment: **Batch status list still shows `task.slug`, not `task.title`** The progress list during bulk creation still identifies tasks by their slug (line 369: `{task.slug}`), while the workspace is now named after their title. This creates a slight UX mismatch — the user sees the slug in the progress list but the workspace opens with the title as its name. Depending on intent, you may want to show `task.title` here (or `task.title ?? task.slug`) so the progress list matches what the user will see in the sidebar. How can I resolve this? If you propose a fix, please make it concise.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Prompt To Fix All With AI
This is a comment left during a code review.
Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/$taskId/components/PropertiesSidebar/components/OpenInWorkspace/OpenInWorkspace.tsx
Line: 124
Comment:
**Possible workspace collision on same-title tasks**
`createWorkspace.mutateAsyncWithPendingSetup` deduplicates by `projectId` + `name` (evidenced by the `result.wasExisting` check). When `name` was `task.slug`, collisions were impossible because slugs are unique per project. Now that `name` is `task.title`, two tasks in the same project that share a title (e.g., both called `"Fix auth middleware"`) will match the same workspace: the second open-in-workspace call will return `wasExisting: true` and launch a new agent session inside the first task's workspace instead of creating a fresh one.
If workspace deduplication is also expected to key on `branchName`, this may be safe, but the code path for `result.wasExisting` only re-runs `launchAgentSession` — it does not verify that the found workspace's branch matches the current task's branch.
Consider appending the slug to keep uniqueness while still showing a human-friendly name, e.g.:
```ts
name: task.title ? `${task.title} (${task.slug})` : task.slug,
```
or guarantee uniqueness by checking whether the backend deduplication key includes `branchName`.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/components/TasksView/components/TasksTopBar/components/RunInWorkspacePopover/RunInWorkspacePopover.tsx
Line: 177
Comment:
**Same workspace-collision risk as in `OpenInWorkspace`**
The same deduplication concern applies here. In the bulk path this is especially impactful: if a user bulk-selects multiple tasks that happen to have the same title, only the first one creates a new workspace; all subsequent ones will hit `wasExisting: true` and inject their agent launch request into the same pre-existing workspace, rather than each getting their own isolated environment.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/$taskId/components/PropertiesSidebar/components/OpenInWorkspace/OpenInWorkspace.tsx
Line: 124
Comment:
**Missing guard for empty/undefined `task.title`**
`task.title` is typed as part of `TaskWithStatus` but tasks can exist in a draft/untitled state (e.g., a task created without a title yet). Passing an empty string or `undefined` as `name` to `createWorkspace` may be rejected by the backend or silently create a workspace with a blank name. The previous `task.slug` was always a non-empty structured identifier.
Consider adding a fallback:
```suggestion
name: task.title || task.slug,
```
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/components/TasksView/components/TasksTopBar/components/RunInWorkspacePopover/RunInWorkspacePopover.tsx
Line: 369
Comment:
**Batch status list still shows `task.slug`, not `task.title`**
The progress list during bulk creation still identifies tasks by their slug (line 369: `{task.slug}`), while the workspace is now named after their title. This creates a slight UX mismatch — the user sees the slug in the progress list but the workspace opens with the title as its name. Depending on intent, you may want to show `task.title` here (or `task.title ?? task.slug`) so the progress list matches what the user will see in the sidebar.
```suggestion
<span className="truncate">{task.title || task.slug}</span>
```
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "fix(desktop): use task title as workspac..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| { | ||
| projectId, | ||
| name: task.slug, | ||
| name: task.title, |
There was a problem hiding this comment.
createWorkspace.mutateAsyncWithPendingSetup deduplicates by projectId + name (evidenced by the result.wasExisting check). When name was task.slug, collisions were impossible because slugs are unique per project. Now that name is task.title, two tasks in the same project that share a title (e.g., both called "Fix auth middleware") will match the same workspace: the second open-in-workspace call will return wasExisting: true and launch a new agent session inside the first task's workspace instead of creating a fresh one.
If workspace deduplication is also expected to key on branchName, this may be safe, but the code path for result.wasExisting only re-runs launchAgentSession — it does not verify that the found workspace's branch matches the current task's branch.
Consider appending the slug to keep uniqueness while still showing a human-friendly name, e.g.:
name: task.title ? `${task.title} (${task.slug})` : task.slug,or guarantee uniqueness by checking whether the backend deduplication key includes branchName.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/$taskId/components/PropertiesSidebar/components/OpenInWorkspace/OpenInWorkspace.tsx
Line: 124
Comment:
**Possible workspace collision on same-title tasks**
`createWorkspace.mutateAsyncWithPendingSetup` deduplicates by `projectId` + `name` (evidenced by the `result.wasExisting` check). When `name` was `task.slug`, collisions were impossible because slugs are unique per project. Now that `name` is `task.title`, two tasks in the same project that share a title (e.g., both called `"Fix auth middleware"`) will match the same workspace: the second open-in-workspace call will return `wasExisting: true` and launch a new agent session inside the first task's workspace instead of creating a fresh one.
If workspace deduplication is also expected to key on `branchName`, this may be safe, but the code path for `result.wasExisting` only re-runs `launchAgentSession` — it does not verify that the found workspace's branch matches the current task's branch.
Consider appending the slug to keep uniqueness while still showing a human-friendly name, e.g.:
```ts
name: task.title ? `${task.title} (${task.slug})` : task.slug,
```
or guarantee uniqueness by checking whether the backend deduplication key includes `branchName`.
How can I resolve this? If you propose a fix, please make it concise.| { | ||
| projectId: effectiveProjectId, | ||
| name: task.slug, | ||
| name: task.title, |
There was a problem hiding this comment.
OpenInWorkspace
The same deduplication concern applies here. In the bulk path this is especially impactful: if a user bulk-selects multiple tasks that happen to have the same title, only the first one creates a new workspace; all subsequent ones will hit wasExisting: true and inject their agent launch request into the same pre-existing workspace, rather than each getting their own isolated environment.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/components/TasksView/components/TasksTopBar/components/RunInWorkspacePopover/RunInWorkspacePopover.tsx
Line: 177
Comment:
**Same workspace-collision risk as in `OpenInWorkspace`**
The same deduplication concern applies here. In the bulk path this is especially impactful: if a user bulk-selects multiple tasks that happen to have the same title, only the first one creates a new workspace; all subsequent ones will hit `wasExisting: true` and inject their agent launch request into the same pre-existing workspace, rather than each getting their own isolated environment.
How can I resolve this? If you propose a fix, please make it concise.| { | ||
| projectId, | ||
| name: task.slug, | ||
| name: task.title, |
There was a problem hiding this comment.
task.title
task.title is typed as part of TaskWithStatus but tasks can exist in a draft/untitled state (e.g., a task created without a title yet). Passing an empty string or undefined as name to createWorkspace may be rejected by the backend or silently create a workspace with a blank name. The previous task.slug was always a non-empty structured identifier.
Consider adding a fallback:
| name: task.title, | |
| name: task.title || task.slug, |
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/$taskId/components/PropertiesSidebar/components/OpenInWorkspace/OpenInWorkspace.tsx
Line: 124
Comment:
**Missing guard for empty/undefined `task.title`**
`task.title` is typed as part of `TaskWithStatus` but tasks can exist in a draft/untitled state (e.g., a task created without a title yet). Passing an empty string or `undefined` as `name` to `createWorkspace` may be rejected by the backend or silently create a workspace with a blank name. The previous `task.slug` was always a non-empty structured identifier.
Consider adding a fallback:
```suggestion
name: task.title || task.slug,
```
How can I resolve this? If you propose a fix, please make it concise.
upstream 取り込み PR #11: use task title as workspace name (superset-sh#3678)
Kitenite
deleted the
saddlepaddle/linear-integration-techniques-and-methods
branch
1 participant
Summary
task.titleinstead oftask.slug, so the sidebar shows e.g. "Fix auth middleware" rather than "SUPER-172".deriveBranchName({slug, title})(e.g.super-172-fix-auth-middleware), so the Linear/GitHub identifier stays in the branch for traceability.Test plan
Summary by cubic
Use the task title as the workspace name when opening a task, so users see a human-readable name instead of the slug. Branch names are unchanged and still include the Linear/GitHub identifier via
deriveBranchName({ slug, title }).Written for commit 21e0284. Summary will update on new commits.
Summary by CodeRabbit