fix(sidebar): create task under correct project when using + button

[naaa760]

summary

• Clicking the + next to a project in the sidebar now always creates the new task under that project. The project is passed into the task modal and into create-task so it no longer depends on ref/state timing.

Fixes

• Fixes the bug where the sidebar + button sometimes created a task under the wrong project (often the first one).

Snapshot

• No screenshots. After the fix, creating a task via + on any project row keeps the task under that project.

Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Mandatory Tasks

[ ] I have self-reviewed the code
[ ] A decent size PR without self-review might be rejected

Checklist

[ ] I have read the contributing guide
[ ] My code follows the style guidelines of this project (pnpm run format)
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have checked if my PR needs changes to the documentation
[ ] I have checked if my changes generate no new warnings (pnpm run lint)
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I haven't checked if new and existing unit tests pass locally with my changes

fix : #1400

[vercel]

@naaa760 is attempting to deploy a commit to the General Action Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR fixes the bug where clicking the + button next to a project in the sidebar would sometimes create a new task under the wrong project. The root cause was a race condition where pendingTaskProjectRef.current could be stale or reset before handleCreateTask consumed it.

What actually fixes the bug: The removal of pendingTaskProjectRef.current = targetProject from handleStartCreateTaskFromSidebar eliminates the race condition. activateProjectView(targetProject) is still called first, which synchronously calls setSelectedProject, and by the time the user interacts with the modal handleCreateTask correctly falls back to the updated selectedProject.

Dead code introduced:

• initialProject is passed to showModal('taskModal', ...) but TaskModalOverlay is typed as TaskModalOverlayProps (only onSuccess/onClose), so the prop is never consumed and likely triggers a TypeScript excess-property error.
• overrideProject?: Project was added as the 14th argument to handleCreateTask, but TaskModalProps.onCreateTask only has 13 parameters, making this argument unreachable through the modal submission path.

Confidence Score: 3/5

• The PR fixes the bug in practice but introduces dead code that may cause TypeScript compilation errors and could mislead future contributors.
• The practical fix (removing the racy ref write, relying on selectedProject) works correctly. However, initialProject passed to showModal is not a valid prop on TaskModalOverlayProps (likely a TypeScript error), and overrideProject in handleCreateTask is unreachable from TaskModalOverlay. These reduce confidence since the intended explicit-passing mechanism isn't actually wired through, and the stray type-unsafe prop may block the build.
• src/renderer/hooks/useTaskManagement.ts — the initialProject/overrideProject additions need either proper wiring or removal

Important Files Changed

Filename	Overview
src/renderer/hooks/useTaskManagement.ts	Bug fix for sidebar task creation: removes the racy pendingTaskProjectRef assignment and relies on activateProjectView to set selectedProject before the modal opens. The fix works at runtime, but the added initialProject prop (passed to showModal) and overrideProject parameter (added to handleCreateTask) are dead code — neither is consumed through the modal call chain.

Sequence Diagram

sequenceDiagram
    participant User
    participant Sidebar
    participant handleStartCreateTaskFromSidebar
    participant activateProjectView
    participant openTaskModal
    participant openTaskModalImplRef
    participant showModal
    participant TaskModalOverlay
    participant handleCreateTask

    User->>Sidebar: clicks + next to Project X
    Sidebar->>handleStartCreateTaskFromSidebar: project X
    handleStartCreateTaskFromSidebar->>activateProjectView: targetProject (sets selectedProject = X)
    handleStartCreateTaskFromSidebar->>openTaskModal: targetProject
    openTaskModal->>openTaskModalImplRef: project X
    Note over openTaskModalImplRef: initialProject = X (passed but unused by overlay)
    openTaskModalImplRef->>showModal: taskModal, {initialProject: X, onClose}
    showModal->>TaskModalOverlay: renders (reads selectedProject=X from context)
    User->>TaskModalOverlay: fills form, submits
    TaskModalOverlay->>handleCreateTask: (name, ...args, nameGenerated) — no overrideProject
    Note over handleCreateTask: overrideProject=undefined, pendingTaskProjectRef=null\n→ falls back to selectedProject (= X) ✓
    handleCreateTask-->>User: task created under Project X

Loading

Comments Outside Diff (2)

1. src/renderer/hooks/useTaskManagement.ts, line 966-974 (link)

   initialProject passed to showModal is silently ignored

   initialProject is included in the showModal('taskModal', ...) args, but TaskModalOverlay is typed as TaskModalOverlayProps = BaseModalProps<CreateTaskResult> which only exposes onSuccess and onClose. The component signature TaskModalOverlay({ onClose }: TaskModalOverlayProps) never destructures or uses initialProject.

   Because UserArgs<'taskModal'> resolves to { onSuccess?: ...; onClose?: ... } (the non-onSuccess/onClose remainder of TaskModalOverlayProps is empty), passing initialProject here is a TypeScript excess-property violation that will surface under strict mode.

   More importantly, even at runtime the prop is a no-op — TaskModal still reads selectedProject from useProjectManagementContext() for the branch display and name de-duplication, not from any initialProject passed down.

   The actual reason the bug is fixed is that activateProjectView(targetProject) calls setSelectedProject(project) first, so by the time the user can submit the form, handleCreateTask correctly closes over the updated selectedProject value. The initialProject / overrideProject plumbing added by this PR is dead code that does not contribute to the fix. Consider either wiring it through properly (update TaskModalOverlayProps, pass initialProject to TaskModal, and forward overrideProject in TaskModalOverlay.onCreateTask) or removing it to keep the change minimal.

2. src/renderer/hooks/useTaskManagement.ts, line 910-949 (link)

   overrideProject parameter is unreachable from the modal

   overrideProject was added as the 14th positional argument to handleCreateTask, but TaskModalProps.onCreateTask (lines 58–72 in TaskModal.tsx) only declares 13 parameters and ends with nameGenerated. TaskModalOverlay calls handleCreateTask with exactly those 13 arguments — overrideProject can never be supplied through the current call chain.

   To actually use this escape hatch, TaskModalProps.onCreateTask and the TaskModalOverlay adapter would both need to be extended. Until then the parameter is unreachable dead code.

_{Last reviewed commit: 9d54cb0}