feat: branching tasks#2297
Conversation
Prompt To Fix All With AIFix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
apps/code/src/renderer/features/sessions/components/BranchTaskDialog.tsx:75-76
The `mode` state variable is dead code. `handleSubmit` always passes `mode: "context"` literally (required by `BranchTaskParams.mode: "context"`), and the "context+code" option is permanently disabled, so `setMode` can never change the outcome. The state, its setter call in `onSelect`, and the `BranchMode` type are all superfluous right now — they'll only be needed once "context+code" is actually wired up.
```suggestion
const [isSubmitting, setIsSubmitting] = useState(false);
```
### Issue 2 of 2
apps/code/src/renderer/features/sessions/components/BranchedFromChip.tsx:31
The `as unknown as Task` double-cast bypasses TypeScript entirely. If `client.getTask()` returns a type incompatible with `Task` (e.g., camelCase vs snake_case fields, or extra/missing properties), the cast will silently pass bad data to `navigateToTask`, leading to a runtime error or broken navigation. It's worth aligning the return type of `getTask` with `Task`, or adding a lightweight mapping/assertion here, so the compiler catches any divergence.
Reviews (1): Last reviewed commit: "branching tasks" | Re-trigger Greptile |
| const [mode, setMode] = useState<BranchMode>("context"); | ||
| const [isSubmitting, setIsSubmitting] = useState(false); |
There was a problem hiding this comment.
The
mode state variable is dead code. handleSubmit always passes mode: "context" literally (required by BranchTaskParams.mode: "context"), and the "context+code" option is permanently disabled, so setMode can never change the outcome. The state, its setter call in onSelect, and the BranchMode type are all superfluous right now — they'll only be needed once "context+code" is actually wired up.
| const [mode, setMode] = useState<BranchMode>("context"); | |
| const [isSubmitting, setIsSubmitting] = useState(false); | |
| const [isSubmitting, setIsSubmitting] = useState(false); |
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/components/BranchTaskDialog.tsx
Line: 75-76
Comment:
The `mode` state variable is dead code. `handleSubmit` always passes `mode: "context"` literally (required by `BranchTaskParams.mode: "context"`), and the "context+code" option is permanently disabled, so `setMode` can never change the outcome. The state, its setter call in `onSelect`, and the `BranchMode` type are all superfluous right now — they'll only be needed once "context+code" is actually wired up.
```suggestion
const [isSubmitting, setIsSubmitting] = useState(false);
```
How can I resolve this? If you propose a fix, please make it concise.| if (!client) return; | ||
| try { | ||
| const parent = await client.getTask(lineage.parentTaskId); | ||
| navigateToTask(parent as unknown as Task); |
There was a problem hiding this comment.
The
as unknown as Task double-cast bypasses TypeScript entirely. If client.getTask() returns a type incompatible with Task (e.g., camelCase vs snake_case fields, or extra/missing properties), the cast will silently pass bad data to navigateToTask, leading to a runtime error or broken navigation. It's worth aligning the return type of getTask with Task, or adding a lightweight mapping/assertion here, so the compiler catches any divergence.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/components/BranchedFromChip.tsx
Line: 31
Comment:
The `as unknown as Task` double-cast bypasses TypeScript entirely. If `client.getTask()` returns a type incompatible with `Task` (e.g., camelCase vs snake_case fields, or extra/missing properties), the cast will silently pass bad data to `navigateToTask`, leading to a runtime error or broken navigation. It's worth aligning the return type of `getTask` with `Task`, or adding a lightweight mapping/assertion here, so the compiler catches any divergence.
How can I resolve this? If you propose a fix, please make it concise.
Problem
Tasks are fully isolated, there's no way to spin off a new task that continues from where another one is, with its context carried over.
Changes
Adds a Branch task action to the task header. Branching summarises the current conversation (LLM call) and creates a new task seeded with that summary as its starting context. The new task starts from a clean tree carrying over code changes would also be nice but not in scope of this PR. A "Branched from #N" chip links a branched task back to its parent.
https://posthog.slack.com/archives/C09G8Q32R6F/p1779459522870039?thread_ts=1779447719.812489&cid=C09G8Q32R6F
How did you test this?
ran local test
and added 2 new tests branchContext.test.ts
,generateBranchSummary.test.ts`Publish to changelog?
Yes "Branch a task to start a new one that continues with its context."