[P1] Task approval button not visible in planning phase projects

[frankbria]

Problem

The "Approve Tasks" button is not visible for projects in the planning phase with pending tasks, causing E2E test failures.

Failing Test

test_task_approval.spec.ts:149 - should handle 422 validation error gracefully

Error

Error: expect(locator).toBeVisible() failed
Locator: getByRole('button', { name: /approve/i })
Expected: visible
Timeout: 5000ms
Error: element(s) not found

Context

• Test uses project ID 2 which is seeded in 'planning' phase with 4 pending tasks
• The approve button should appear when there are pending tasks awaiting approval
• Task approval flow test sequence depends on this button being visible

Possible Root Causes

1. TaskReview component not rendering for planning phase
2. Approve button conditional logic incorrect (checking wrong phase/status)
3. Pending tasks not being loaded from API correctly
4. Button visibility depends on some other UI state not met

Seeding Verification

📋 Seeding issues for project 2 (planning phase task approval)...
✅ Seeded 3/3 issues for project 2
✅ Seeded 4 tasks for project 2

Expected Behavior

When a project is in planning phase with pending tasks:

1. User navigates to project dashboard
2. Tasks tab shows pending tasks awaiting approval
3. "Approve Tasks" or similar button is visible
4. Clicking the button triggers the approval API

Affected Files

• web-ui/src/components/TaskReview.tsx (or equivalent)
• web-ui/src/components/Dashboard.tsx
• tests/e2e/test_task_approval.spec.ts

[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

• 016-5: TaskReview Component - Task Approval UI #202

🔗 Related PRs

#211 - feat(dashboard): Add PhaseProgress component for phase visualization [merged]
#213 - feat(planning): Add Generate Task Breakdown button to DiscoveryProgress [merged]
#214 - feat(planning): Add TaskReview component for task approval workflow [merged]
#215 - feat(dashboard): Add phase-aware task view integration (#16-6) [merged]
#240 - fix(api): align task approval request body with backend contract [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!

[traycerai]

Plan

Observations

The E2E test test_task_approval.spec.ts:149 fails because the "Approve Tasks" button is not visible when navigating to a planning phase project. The test expects to find the button using page.getByRole('button', { name: /approve/i }) but it times out after 5 seconds. Project 2 is correctly seeded in 'planning' phase with 4 pending tasks (3 issues with nested tasks). The TaskReview component contains the approve button and should render when normalizePhase(projectData.phase) === 'planning' in file:web-ui/src/components/Dashboard.tsx (line 713).

Approach

The root cause is likely a conditional rendering issue in the Dashboard component where the TaskReview component is not being rendered for planning phase projects. The investigation reveals that the Dashboard correctly checks for planning phase at line 713, but there may be a race condition or the phase value is not being properly normalized. The solution involves ensuring the TaskReview component renders reliably for planning phase projects by adding defensive checks and improving the conditional logic. Additionally, verify that the API response includes the phase field and that the SWR data fetching completes before rendering phase-dependent components.

Implementation Steps

1. Verify API Response Structure

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

Confirm that the /api/projects/{project_id}/status endpoint (line 251-278) returns the phase field correctly:

• Ensure project["phase"] is always present in the response (line 275)
• Add logging to verify the phase value being returned for project 2
• Verify that the database query in db.get_project(project_id) returns the phase field

2. Add Defensive Checks in Dashboard Component

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

Strengthen the conditional rendering logic for the Tasks tab (lines 700-761):

• Add explicit null/undefined checks for projectData.phase before calling normalizePhase()
• Add console logging to debug the phase value and normalized phase value
• Ensure the loading state check (line 329-331) waits for both projectData AND projectData.phase to be defined
• Consider adding a separate loading state for the Tasks tab content while phase data is being fetched

Specific changes needed:

• Line 329: Update the loading check to verify projectData and projectData.phase exist
• Line 713: Add explicit check: projectData?.phase && normalizePhase(projectData.phase) === 'planning'
• Add debug logging before the conditional to log: projectData.phase, normalizePhase(projectData.phase), and the condition result

3. Verify TaskReview Component Rendering

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

Ensure the TaskReview component renders the approve button correctly:

• Verify the component receives the correct projectId prop (line 726 in Dashboard)
• Check that the issues fetch (line 99) includes the include: 'tasks' parameter
• Confirm the empty state check (line 302-308) doesn't incorrectly hide the button when tasks exist
• Verify the button is not disabled due to selectedTaskIds.size === 0 (line 474)
• Add logging in the fetchIssues callback (line 94-117) to verify issues and tasks are loaded

Specific checks:

• Line 99: Confirm projectsApi.getIssues(projectId, { include: 'tasks' }) is called correctly
• Line 104-105: Verify allTaskIds is populated and selectedTaskIds is initialized
• Line 302: Ensure the empty state condition issues.length === 0 || totalTasks === 0 is not triggered incorrectly
• Line 471-478: Verify the button renders and is not disabled

4. Verify Seed Data and API Integration

File: file:tests/e2e/seed-test-data.py

Confirm project 2 seed data is correct (lines 1200-1480):

• Verify phase field is set to 'planning' (line 1227)
• Verify status field is set to 'planning' (line 1226)
• Confirm 3 issues are seeded (lines 1293-1333)
• Confirm 4 tasks are seeded with issue_id foreign keys (lines 1360-1460)
• Verify all tasks have status: 'pending' (lines 1370, 1394, 1419, 1444)

File: file:tests/e2e/e2e-config.ts

Verify TEST_PROJECT_IDS.PLANNING is correctly set to '2' (line 37).

5. Add Test Debugging and Assertions

File: file:tests/e2e/test_task_approval.spec.ts

Enhance the failing test (line 149-201) with better debugging:

• Add logging before checking for the approve button to capture the current phase
• Add a step to verify the project phase via API call before checking UI
• Add explicit wait for the TaskReview component to render (check for role="tree")
• Increase timeout for button visibility check from 5s to 10s
• Add screenshot capture on failure for debugging

Specific improvements:

• Line 168-169: Add API call to verify project phase before navigating
• Line 176-178: Add intermediate assertion for TaskReview component presence
• Line 178: Increase timeout to 10000ms and add better error message
• Add await page.screenshot({ path: 'approve-button-not-found.png' }) on failure

6. Verify Phase Normalization Logic

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

Review the normalizePhase function (lines 64-75):

• Confirm it correctly maps 'planning' → 'planning' (line 68)
• Verify the default fallback to 'discovery' (line 74) doesn't incorrectly trigger for valid planning phase
• Add logging to track phase normalization: input phase → output phase

7. Check for Race Conditions

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

Investigate potential race conditions in data fetching:

• Verify SWR refreshInterval settings (lines 197-237) don't cause premature rendering
• Check if projectData is populated before issuesData completes
• Ensure the Tasks tab waits for both projectData and issuesData before rendering phase-specific components
• Consider adding a combined loading state: !projectData || !issuesData

8. Verify ErrorBoundary Behavior

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

Check if the ErrorBoundary (line 725-727) is catching errors and hiding the TaskReview:

• Add logging inside the ErrorBoundary fallback to detect if it's being triggered
• Verify TaskReview component doesn't throw errors during initialization
• Check browser console for any React errors during test execution

Verification Steps

1. Run the failing E2E test locally: npm run test:e2e -- test_task_approval.spec.ts:149
2. Check browser console logs for phase values and normalization results
3. Verify the TaskReview component renders by checking for role="tree" element
4. Confirm the approve button is present with getByRole('button', { name: /approve/i })
5. Verify the button is not disabled and is clickable
6. Run all task approval tests to ensure no regressions

Expected Outcome

After implementing these changes:

• The Dashboard component will reliably render TaskReview for planning phase projects
• The approve button will be visible and clickable for project 2
• The E2E test test_task_approval.spec.ts:149 will pass consistently
• No race conditions or timing issues will prevent the button from appearing

Import In IDE

🤖 Prompt for AI Agents

## Observations

The E2E test `test_task_approval.spec.ts:149` fails because the "Approve Tasks" button is not visible when navigating to a planning phase project. The test expects to find the button using `page.getByRole('button', { name: /approve/i })` but it times out after 5 seconds. Project 2 is correctly seeded in 'planning' phase with 4 pending tasks (3 issues with nested tasks). The `TaskReview` component contains the approve button and should render when `normalizePhase(projectData.phase) === 'planning'` in `file:web-ui/src/components/Dashboard.tsx` (line 713).

## Approach

The root cause is likely a conditional rendering issue in the Dashboard component where the TaskReview component is not being rendered for planning phase projects. The investigation reveals that the Dashboard correctly checks for planning phase at line 713, but there may be a race condition or the phase value is not being properly normalized. The solution involves ensuring the TaskReview component renders reliably for planning phase projects by adding defensive checks and improving the conditional logic. Additionally, verify that the API response includes the phase field and that the SWR data fetching completes before rendering phase-dependent components.

## Implementation Steps

### 1. Verify API Response Structure
**File:** `file:codeframe/ui/routers/projects.py`

Confirm that the `/api/projects/{project_id}/status` endpoint (line 251-278) returns the `phase` field correctly:
- Ensure `project["phase"]` is always present in the response (line 275)
- Add logging to verify the phase value being returned for project 2
- Verify that the database query in `db.get_project(project_id)` returns the phase field

### 2. Add Defensive Checks in Dashboard Component
**File:** `file:web-ui/src/components/Dashboard.tsx`

Strengthen the conditional rendering logic for the Tasks tab (lines 700-761):

- Add explicit null/undefined checks for `projectData.phase` before calling `normalizePhase()`
- Add console logging to debug the phase value and normalized phase value
- Ensure the loading state check (line 329-331) waits for both `projectData` AND `projectData.phase` to be defined
- Consider adding a separate loading state for the Tasks tab content while phase data is being fetched

**Specific changes needed:**
- Line 329: Update the loading check to verify `projectData` and `projectData.phase` exist
- Line 713: Add explicit check: `projectData?.phase && normalizePhase(projectData.phase) === 'planning'`
- Add debug logging before the conditional to log: `projectData.phase`, `normalizePhase(projectData.phase)`, and the condition result

### 3. Verify TaskReview Component Rendering
**File:** `file:web-ui/src/components/TaskReview.tsx`

Ensure the TaskReview component renders the approve button correctly:

- Verify the component receives the correct `projectId` prop (line 726 in Dashboard)
- Check that the issues fetch (line 99) includes the `include: 'tasks'` parameter
- Confirm the empty state check (line 302-308) doesn't incorrectly hide the button when tasks exist
- Verify the button is not disabled due to `selectedTaskIds.size === 0` (line 474)
- Add logging in the `fetchIssues` callback (line 94-117) to verify issues and tasks are loaded

**Specific checks:**
- Line 99: Confirm `projectsApi.getIssues(projectId, { include: 'tasks' })` is called correctly
- Line 104-105: Verify `allTaskIds` is populated and `selectedTaskIds` is initialized
- Line 302: Ensure the empty state condition `issues.length === 0 || totalTasks === 0` is not triggered incorrectly
- Line 471-478: Verify the button renders and is not disabled

### 4. Verify Seed Data and API Integration
**File:** `file:tests/e2e/seed-test-data.py`

Confirm project 2 seed data is correct (lines 1200-1480):

- Verify `phase` field is set to `'planning'` (line 1227)
- Verify `status` field is set to `'planning'` (line 1226)
- Confirm 3 issues are seeded (lines 1293-1333)
- Confirm 4 tasks are seeded with `issue_id` foreign keys (lines 1360-1460)
- Verify all tasks have `status: 'pending'` (lines 1370, 1394, 1419, 1444)

**File:** `file:tests/e2e/e2e-config.ts`

Verify TEST_PROJECT_IDS.PLANNING is correctly set to '2' (line 37).

### 5. Add Test Debugging and Assertions
**File:** `file:tests/e2e/test_task_approval.spec.ts`

Enhance the failing test (line 149-201) with better debugging:

- Add logging before checking for the approve button to capture the current phase
- Add a step to verify the project phase via API call before checking UI
- Add explicit wait for the TaskReview component to render (check for `role="tree"`)
- Increase timeout for button visibility check from 5s to 10s
- Add screenshot capture on failure for debugging

**Specific improvements:**
- Line 168-169: Add API call to verify project phase before navigating
- Line 176-178: Add intermediate assertion for TaskReview component presence
- Line 178: Increase timeout to 10000ms and add better error message
- Add `await page.screenshot({ path: 'approve-button-not-found.png' })` on failure

### 6. Verify Phase Normalization Logic
**File:** `file:web-ui/src/components/Dashboard.tsx`

Review the `normalizePhase` function (lines 64-75):

- Confirm it correctly maps `'planning'` → `'planning'` (line 68)
- Verify the default fallback to `'discovery'` (line 74) doesn't incorrectly trigger for valid planning phase
- Add logging to track phase normalization: input phase → output phase

### 7. Check for Race Conditions
**File:** `file:web-ui/src/components/Dashboard.tsx`

Investigate potential race conditions in data fetching:

- Verify SWR `refreshInterval` settings (lines 197-237) don't cause premature rendering
- Check if `projectData` is populated before `issuesData` completes
- Ensure the Tasks tab waits for both `projectData` and `issuesData` before rendering phase-specific components
- Consider adding a combined loading state: `!projectData || !issuesData`

### 8. Verify ErrorBoundary Behavior
**File:** `file:web-ui/src/components/Dashboard.tsx`

Check if the ErrorBoundary (line 725-727) is catching errors and hiding the TaskReview:

- Add logging inside the ErrorBoundary fallback to detect if it's being triggered
- Verify TaskReview component doesn't throw errors during initialization
- Check browser console for any React errors during test execution

## Verification Steps

1. Run the failing E2E test locally: `npm run test:e2e -- test_task_approval.spec.ts:149`
2. Check browser console logs for phase values and normalization results
3. Verify the TaskReview component renders by checking for `role="tree"` element
4. Confirm the approve button is present with `getByRole('button', { name: /approve/i })`
5. Verify the button is not disabled and is clickable
6. Run all task approval tests to ensure no regressions

## Expected Outcome

After implementing these changes:
- The Dashboard component will reliably render TaskReview for planning phase projects
- The approve button will be visible and clickable for project 2
- The E2E test `test_task_approval.spec.ts:149` will pass consistently
- No race conditions or timing issues will prevent the button from appearing

---

Execution Information

Branch: main
Commit: 84c9ded

---

💡 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.