[P0] Task Generation button generates 400 error

[frankbria]

When the user logs into a project where Discovery has already completed, there is a Task Generation button. When you press it, the user is presented with an error:

Task Generation Failed Failed to generate tasks: Request failed with status code 400 Retry Task Generation

The browser console shows more detail:

error_handler.js:1 Failed to generate tasks: 
Y
501-0fb0225c0fce04a0.js:1 
 POST https://api.dev.codeframeapp.com/api/projects/2/discovery/generate-tasks 400 (Bad Request)
error_handler.js:1 Failed to generate tasks: 
Y {message: 'Request failed with status code 400', name: 'AxiosError', code: 'ERR_BAD_REQUEST', config: {…}, request: XMLHttpRequest, …}
code
: 
"ERR_BAD_REQUEST"
config
: 
{transitional: {…}, adapter: Array(3), transformRequest: Array(1), transformResponse: Array(1), timeout: 0, …}
message
: 
"Request failed with status code 400"
name
: 
"AxiosError"
request
: 
XMLHttpRequest {onreadystatechange: null, readyState: 4, timeout: 0, withCredentials: false, upload: XMLHttpRequestUpload, …}
response
: 
{data: {…}, status: 400, statusText: '', headers: ej, config: {…}, …}
status
: 
400
stack
: 
"AxiosError: Request failed with status code 400\n    at eN (https://dev.codeframeapp.com/_next/static/chunks/501-0fb0225c0fce04a0.js:1:43191)\n    at XMLHttpRequest.g (https://dev.codeframeapp.com/_next/static/chunks/501-0fb0225c0fce04a0.js:1:47640)\n    at tl.request (https://dev.codeframeapp.com/_next/static/chunks/501-0fb0225c0fce04a0.js:1:56133)\n    at async ew (https://dev.codeframeapp.com/_next/static/chunks/app/projects/%5BprojectId%5D/page-c645049fd51738f6.js:1:32237)"
[[Prototype]]
: 
Error

Expected Output:
The user should be presented with a list of generated tasks in order to begin development on one of them.

[traycerai]

Plan

Observations

The issue occurs when a user logs into a project where Discovery has completed and tasks have already been auto-generated. The frontend shows a "Generate Task Breakdown" button because it doesn't check if tasks exist on mount—it only knows about tasks through real-time WebSocket events. When clicked, the backend returns a 400 error because file:codeframe/ui/routers/discovery.py (lines 695-701) validates that tasks don't already exist. This validation prevents duplicate generation but creates a poor UX when users miss the WebSocket events.

Approach

Implement a hybrid solution addressing both frontend and backend issues. The frontend will check task existence on component mount to properly initialize UI state, preventing the button from appearing when tasks already exist. The backend will provide a more informative error response that distinguishes between "tasks already exist" and other validation failures, allowing the frontend to handle this case gracefully. This approach ensures defensive programming on both sides while maintaining data integrity.

Implementation Steps

1. Frontend: Initialize Task State on Component Mount

File: file:web-ui/src/components/DiscoveryProgress.tsx

Modify the fetchProgress function (around line 156) to also check if tasks exist when initializing PRD state:

• After checking PRD status (lines 164-186), add a task existence check
• Call tasksApi.list(projectId, { limit: 1 }) to check if any tasks exist
• If total > 0, set setTasksGenerated(true) to hide the button
• Wrap in try-catch to handle errors gracefully (don't block UI if task fetch fails)
• Only perform this check when initializePrdState is true and phase is 'planning'

This ensures the button doesn't appear when tasks already exist, even if the user missed WebSocket events.

2. Backend: Improve Error Response for Existing Tasks

File: file:codeframe/ui/routers/discovery.py

Modify the generate_tasks endpoint (lines 638-719) to provide a more informative error:

• Change the HTTPException at lines 704-707 to include a specific error code
• Update the detail message to: "Tasks have already been generated for this project. Please refresh the page to see existing tasks."
• Consider adding a custom error field like "error_code": "TASKS_ALREADY_EXIST" in the response body
• Alternatively, make the endpoint idempotent by checking if tasks exist and returning success with a message like "Tasks already exist" instead of raising an error

Recommended approach: Return a 200 response with a flag indicating tasks already exist:

if existing_tasks:
    return {
        "success": True,
        "message": "Tasks have already been generated for this project.",
        "tasks_already_exist": True,
    }

This makes the endpoint idempotent and provides better UX.

3. Frontend: Handle Backend Response Gracefully

File: file:web-ui/src/components/DiscoveryProgress.tsx

Update the handleGenerateTaskBreakdown function (lines 269-289):

• Check the response for tasks_already_exist flag
• If true, set setTasksGenerated(true) and setIsGeneratingTasks(false)
• Show a success message instead of an error
• Optionally trigger a refresh to load existing tasks

If keeping the 400 error approach, improve error handling:

• Parse the error response to detect "already generated" case
• Show a user-friendly message: "Tasks have already been generated. Refreshing..."
• Automatically set tasksGenerated = true and hide the button
• Trigger a page refresh or task list fetch

4. Update Tests

File: file:tests/api/test_generate_tasks_endpoint.py

Update the test at lines 194-222 (test_returns_400_when_tasks_already_exist):

• If implementing idempotent approach, change expected status code from 400 to 200
• Verify response includes tasks_already_exist: true flag
• Update assertion to check for success message

File: file:web-ui/__tests__/components/DiscoveryProgress.test.tsx

Add new test cases:

• Test that component initializes tasksGenerated = true when tasks exist on mount
• Test that button is hidden when tasks already exist
• Test that clicking button when tasks exist shows appropriate message
• Mock tasksApi.list to return tasks in the test setup

5. WebSocket Event Handling (Optional Enhancement)

File: file:web-ui/src/components/DiscoveryProgress.tsx

Consider adding a WebSocket event listener for when another user/session generates tasks:

• Listen for tasks_ready event even when not actively generating
• Update tasksGenerated state when event is received
• This handles the edge case where tasks are generated in another browser tab/session

Sequence Diagram

sequenceDiagram
    participant User
    participant Frontend
    participant Backend
    participant Database

    User->>Frontend: Logs in and views project
    Frontend->>Backend: GET /api/projects/{id}/discovery/progress
    Backend-->>Frontend: {phase: "planning", discovery: {state: "completed"}}
    
    Frontend->>Backend: GET /api/projects/{id}/tasks?limit=1
    Backend->>Database: get_project_tasks(project_id)
    Database-->>Backend: [existing tasks]
    Backend-->>Frontend: {tasks: [...], total: 5}
    
    Frontend->>Frontend: setTasksGenerated(true)
    Frontend->>User: Shows "Tasks Ready" section (button hidden)
    
    Note over User,Database: Alternative flow: No tasks exist yet
    
    User->>Frontend: Clicks "Generate Task Breakdown"
    Frontend->>Backend: POST /api/projects/{id}/discovery/generate-tasks
    Backend->>Database: get_project_tasks(project_id)
    Database-->>Backend: []
    Backend->>Backend: Trigger generate_planning_background()
    Backend-->>Frontend: {success: true, message: "Task generation started"}
    Frontend->>Frontend: setIsGeneratingTasks(true)
    
    Backend->>Frontend: WebSocket: planning_started
    Backend->>Frontend: WebSocket: issues_generated
    Backend->>Frontend: WebSocket: tasks_decomposed
    Backend->>Frontend: WebSocket: tasks_ready
    Frontend->>Frontend: setTasksGenerated(true)
    Frontend->>User: Shows "Tasks Ready" section

Loading

Import In IDE

🤖 Prompt for AI Agents

## Observations

The issue occurs when a user logs into a project where Discovery has completed and tasks have already been auto-generated. The frontend shows a "Generate Task Breakdown" button because it doesn't check if tasks exist on mount—it only knows about tasks through real-time WebSocket events. When clicked, the backend returns a 400 error because `file:codeframe/ui/routers/discovery.py` (lines 695-701) validates that tasks don't already exist. This validation prevents duplicate generation but creates a poor UX when users miss the WebSocket events.

## Approach

Implement a hybrid solution addressing both frontend and backend issues. The frontend will check task existence on component mount to properly initialize UI state, preventing the button from appearing when tasks already exist. The backend will provide a more informative error response that distinguishes between "tasks already exist" and other validation failures, allowing the frontend to handle this case gracefully. This approach ensures defensive programming on both sides while maintaining data integrity.

## Implementation Steps

### 1. Frontend: Initialize Task State on Component Mount

**File:** `file:web-ui/src/components/DiscoveryProgress.tsx`

Modify the `fetchProgress` function (around line 156) to also check if tasks exist when initializing PRD state:

- After checking PRD status (lines 164-186), add a task existence check
- Call `tasksApi.list(projectId, { limit: 1 })` to check if any tasks exist
- If `total > 0`, set `setTasksGenerated(true)` to hide the button
- Wrap in try-catch to handle errors gracefully (don't block UI if task fetch fails)
- Only perform this check when `initializePrdState` is true and phase is 'planning'

This ensures the button doesn't appear when tasks already exist, even if the user missed WebSocket events.

### 2. Backend: Improve Error Response for Existing Tasks

**File:** `file:codeframe/ui/routers/discovery.py`

Modify the `generate_tasks` endpoint (lines 638-719) to provide a more informative error:

- Change the HTTPException at lines 704-707 to include a specific error code
- Update the detail message to: `"Tasks have already been generated for this project. Please refresh the page to see existing tasks."`
- Consider adding a custom error field like `"error_code": "TASKS_ALREADY_EXIST"` in the response body
- Alternatively, make the endpoint idempotent by checking if tasks exist and returning success with a message like `"Tasks already exist"` instead of raising an error

**Recommended approach:** Return a 200 response with a flag indicating tasks already exist:

```
if existing_tasks:
    return {
        "success": True,
        "message": "Tasks have already been generated for this project.",
        "tasks_already_exist": True,
    }
```

This makes the endpoint idempotent and provides better UX.

### 3. Frontend: Handle Backend Response Gracefully

**File:** `file:web-ui/src/components/DiscoveryProgress.tsx`

Update the `handleGenerateTaskBreakdown` function (lines 269-289):

- Check the response for `tasks_already_exist` flag
- If true, set `setTasksGenerated(true)` and `setIsGeneratingTasks(false)`
- Show a success message instead of an error
- Optionally trigger a refresh to load existing tasks

If keeping the 400 error approach, improve error handling:

- Parse the error response to detect "already generated" case
- Show a user-friendly message: "Tasks have already been generated. Refreshing..."
- Automatically set `tasksGenerated = true` and hide the button
- Trigger a page refresh or task list fetch

### 4. Update Tests

**File:** `file:tests/api/test_generate_tasks_endpoint.py`

Update the test at lines 194-222 (`test_returns_400_when_tasks_already_exist`):

- If implementing idempotent approach, change expected status code from 400 to 200
- Verify response includes `tasks_already_exist: true` flag
- Update assertion to check for success message

**File:** `file:web-ui/__tests__/components/DiscoveryProgress.test.tsx`

Add new test cases:

- Test that component initializes `tasksGenerated = true` when tasks exist on mount
- Test that button is hidden when tasks already exist
- Test that clicking button when tasks exist shows appropriate message
- Mock `tasksApi.list` to return tasks in the test setup

### 5. WebSocket Event Handling (Optional Enhancement)

**File:** `file:web-ui/src/components/DiscoveryProgress.tsx`

Consider adding a WebSocket event listener for when another user/session generates tasks:

- Listen for `tasks_ready` event even when not actively generating
- Update `tasksGenerated` state when event is received
- This handles the edge case where tasks are generated in another browser tab/session

## Sequence Diagram

```mermaid
sequenceDiagram
    participant User
    participant Frontend
    participant Backend
    participant Database

    User->>Frontend: Logs in and views project
    Frontend->>Backend: GET /api/projects/{id}/discovery/progress
    Backend-->>Frontend: {phase: "planning", discovery: {state: "completed"}}
    
    Frontend->>Backend: GET /api/projects/{id}/tasks?limit=1
    Backend->>Database: get_project_tasks(project_id)
    Database-->>Backend: [existing tasks]
    Backend-->>Frontend: {tasks: [...], total: 5}
    
    Frontend->>Frontend: setTasksGenerated(true)
    Frontend->>User: Shows "Tasks Ready" section (button hidden)
    
    Note over User,Database: Alternative flow: No tasks exist yet
    
    User->>Frontend: Clicks "Generate Task Breakdown"
    Frontend->>Backend: POST /api/projects/{id}/discovery/generate-tasks
    Backend->>Database: get_project_tasks(project_id)
    Database-->>Backend: []
    Backend->>Backend: Trigger generate_planning_background()
    Backend-->>Frontend: {success: true, message: "Task generation started"}
    Frontend->>Frontend: setIsGeneratingTasks(true)
    
    Backend->>Frontend: WebSocket: planning_started
    Backend->>Frontend: WebSocket: issues_generated
    Backend->>Frontend: WebSocket: tasks_decomposed
    Backend->>Frontend: WebSocket: tasks_ready
    Frontend->>Frontend: setTasksGenerated(true)
    Frontend->>User: Shows "Tasks Ready" section
```

---

Execution Information

Branch: main
Commit: d2bfd90

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

⚠️ Possible Duplicate Issue

• [P0] Task Generation fails #218

🔗 Related PRs

#213 - feat(planning): Add Generate Task Breakdown button to DiscoveryProgress [merged]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!