E2E Smoke Tests failing

[frankbria]

The following frontend smoke tests are failing:

23 failed
[chromium] › test_checkpoint_ui.spec.ts:39:7 › Checkpoint UI Workflow › should display checkpoint panel
[chromium] › test_checkpoint_ui.spec.ts:58:7 › Checkpoint UI Workflow › should list existing checkpoints
[chromium] › test_checkpoint_ui.spec.ts:94:7 › Checkpoint UI Workflow › should open create checkpoint modal
[chromium] › test_checkpoint_ui.spec.ts:111:7 › Checkpoint UI Workflow › should validate checkpoint name input
[chromium] › test_dashboard.spec.ts:122:7 › Dashboard - Sprint 10 Features › should display all main dashboard sections
[chromium] › test_dashboard.spec.ts:159:7 › Dashboard - Sprint 10 Features › should display review findings panel
[chromium] › test_dashboard.spec.ts:194:7 › Dashboard - Sprint 10 Features › should display quality gates panel
[chromium] › test_dashboard.spec.ts:235:7 › Dashboard - Sprint 10 Features › should display checkpoint panel
[chromium] › test_dashboard.spec.ts:251:7 › Dashboard - Sprint 10 Features › should display metrics and cost tracking panel
[chromium] › test_dashboard.spec.ts:274:7 › Dashboard - Sprint 10 Features › should receive real-time updates via WebSocket
[chromium] › test_dashboard.spec.ts:357:7 › Dashboard - Sprint 10 Features › should display task progress and statistics
[chromium] › test_dashboard.spec.ts:378:7 › Dashboard - Sprint 10 Features › should display agent status information
[chromium] › test_dashboard.spec.ts:406:7 › Dashboard - Sprint 10 Features › should be responsive on mobile viewport
[chromium] › test_metrics_ui.spec.ts:47:7 › Metrics Dashboard UI › should display metrics panel
[chromium] › test_metrics_ui.spec.ts:67:7 › Metrics Dashboard UI › should display total cost ───
[chromium] › test_metrics_ui.spec.ts:83:7 › Metrics Dashboard UI › should display token usage statistics
[chromium] › test_metrics_ui.spec.ts:102:7 › Metrics Dashboard UI › should display token usage chart
[chromium] › test_metrics_ui.spec.ts:116:7 › Metrics Dashboard UI › should display cost breakdown by agent
[chromium] › test_metrics_ui.spec.ts:147:7 › Metrics Dashboard UI › should display cost breakdown by model
[chromium] › test_metrics_ui.spec.ts:241:7 › Metrics Dashboard UI › should display cost per task
[chromium] › test_metrics_ui.spec.ts:297:7 › Metrics Dashboard UI › should refresh metrics in real-time
[chromium] › test_metrics_ui.spec.ts:332:7 › Metrics Dashboard UI › should display cost trend chart
[chromium] › test_review_ui.spec.ts:34:7 › Review Findings UI › should display review findings panel
1 flaky
[chromium] › test_metrics_ui.spec.ts:183:7 › Metrics Dashboard UI › should filter metrics by date range

[traycerai]

Plan

Observations

The E2E smoke tests are failing because the test components cannot find the expected DOM elements with data-testid attributes. After reviewing the codebase, I found that:

1. The frontend components (file:web-ui/src/components/Dashboard.tsx, file:web-ui/src/components/checkpoints/CheckpointList.tsx, file:web-ui/src/components/metrics/CostDashboard.tsx, file:web-ui/src/components/reviews/ReviewSummary.tsx) have the correct data-testid attributes
2. The test setup (file:tests/e2e/global-setup.ts) seeds comprehensive test data including agents, tasks, reviews, checkpoints, and metrics
3. The tests use proper wait strategies and timeout configurations

The root cause is likely that the backend API endpoints are not returning data correctly or the frontend is not rendering due to API errors, causing the tests to timeout waiting for elements that never appear.

Approach

The implementation plan focuses on diagnosing and fixing the API/data flow issues that prevent the frontend components from rendering properly during E2E tests. The approach involves:

1. Verify backend API endpoints are returning the expected data structure
2. Check database seeding to ensure test data is properly inserted
3. Add error handling and logging to identify where the data flow breaks
4. Fix API response issues if data structure mismatches exist
5. Update test assertions to handle edge cases (empty states, loading states)

This approach addresses the symptom (failing tests) by fixing the underlying cause (API/data issues) rather than just adjusting test timeouts or selectors.

Implementation Steps

1. Verify Backend API Endpoints

Objective: Ensure all API endpoints used by the failing tests return data in the expected format.

Files to check:

• file:codeframe/ui/routers/checkpoints.py - Checkpoint list endpoint
• file:codeframe/ui/routers/metrics.py - Metrics/cost endpoints
• file:codeframe/ui/routers/review.py - Review findings endpoint
• file:codeframe/ui/routers/projects.py - Project status endpoint

Actions:

1. Review each router file to verify endpoint implementations match the frontend API client expectations
2. Check that response models include all required fields (e.g., data-testid expects specific field names)
3. Verify database queries return seeded test data correctly
4. Add logging to track API request/response flow during tests

Key areas to verify:

• Checkpoint list endpoint returns checkpoints array with id, name, created_at, git_commit, metadata fields
• Metrics endpoint returns total_cost_usd, by_agent, by_model breakdown
• Review endpoint returns findings array with severity, category, file_path, message fields
• Project status endpoint returns progress, agents, tasks data

2. Validate Database Seeding

Objective: Confirm test data is properly inserted into the SQLite database before tests run.

Files to check:

• file:tests/e2e/seed-test-data.py - Data seeding script
• file:tests/e2e/global-setup.ts - Test setup orchestration

Actions:

1. Add verification queries after seeding to confirm data exists
2. Check for SQL constraint violations or foreign key errors during seeding
3. Verify checkpoint files are created on disk (not just DB records)
4. Add debug logging to show seeded record counts

Verification queries to add:

# After seeding, verify counts
cursor.execute("SELECT COUNT(*) FROM checkpoints WHERE project_id = ?", (project_id,))
checkpoint_count = cursor.fetchone()[0]
print(f"✅ Seeded {checkpoint_count} checkpoints")

cursor.execute("SELECT COUNT(*) FROM token_usage WHERE project_id = ?", (project_id,))
token_count = cursor.fetchone()[0]
print(f"✅ Seeded {token_count} token usage records")

cursor.execute("SELECT COUNT(*) FROM code_reviews WHERE project_id = ?", (project_id,))
review_count = cursor.fetchone()[0]
print(f"✅ Seeded {review_count} code reviews")

3. Add Frontend Error Handling

Objective: Improve error visibility when API calls fail during tests.

Files to modify:

• file:web-ui/src/components/checkpoints/CheckpointList.tsx
• file:web-ui/src/components/metrics/CostDashboard.tsx
• file:web-ui/src/components/reviews/ReviewSummary.tsx

Actions:

1. Add error state display with data-testid="error-message" for test visibility
2. Log API errors to browser console with request details
3. Add loading state indicators with data-testid="loading-spinner"
4. Ensure empty states have proper data-testid attributes

Example error handling pattern:

// In component's useEffect or data fetching logic
try {
  const data = await fetchData();
  setData(data);
} catch (error) {
  console.error('[ComponentName] API Error:', error);
  setError(error.message);
}

// In render
{error && (
  <div data-testid="error-message" className="text-destructive">
    Error loading data: {error}
  </div>
)}

4. Fix API Response Structure Mismatches

Objective: Align backend response structure with frontend expectations.

Common issues to check:

1. Checkpoint metadata: Frontend expects metadata.tasks_completed, metadata.agents_active, etc.
2. Cost breakdown: Frontend expects by_agent and by_model arrays with specific field names
3. Review findings: Frontend expects findings array with severity, category, recommendation fields
4. Task statistics: Dashboard expects total_tasks, completed_tasks, blocked_tasks, in_progress_tasks

Actions:

1. Compare API response models in backend routers with TypeScript types in frontend
2. Add missing fields to backend responses
3. Rename fields if naming mismatch exists
4. Add default values for optional fields to prevent undefined errors

Files to align:

• Backend: file:codeframe/ui/routers/*.py response models
• Frontend: file:web-ui/src/types/*.ts type definitions
• API clients: file:web-ui/src/api/*.ts request/response handling

5. Update Test Assertions for Edge Cases

Objective: Make tests more resilient to timing issues and empty states.

Files to modify:

• file:tests/e2e/test_checkpoint_ui.spec.ts
• file:tests/e2e/test_dashboard.spec.ts
• file:tests/e2e/test_metrics_ui.spec.ts
• file:tests/e2e/test_review_ui.spec.ts

Actions:

1. Add explicit waits for API responses before checking DOM elements
2. Handle both data and empty state scenarios in assertions
3. Add retry logic for flaky WebSocket tests
4. Increase timeouts for slow-loading components

Example improved assertion:

// Before: Assumes data exists
await expect(page.locator('[data-testid="checkpoint-list"]')).toBeVisible();

// After: Handles both data and empty state
const checkpointList = page.locator('[data-testid="checkpoint-list"]');
await checkpointList.waitFor({ state: 'visible', timeout: 15000 });

// Check for either checkpoints or empty state
const hasCheckpoints = await page.locator('[data-testid^="checkpoint-item-"]').count() > 0;
const hasEmptyState = await page.locator('[data-testid="checkpoint-empty-state"]').isVisible();
expect(hasCheckpoints || hasEmptyState).toBe(true);

6. Add Debug Logging to Tests

Objective: Capture diagnostic information when tests fail.

Actions:

1. Log API response status codes and bodies
2. Take screenshots before assertions
3. Capture browser console errors
4. Log component render states

Example debug logging:

// In test beforeEach
page.on('console', msg => console.log('Browser:', msg.text()));
page.on('pageerror', err => console.error('Page error:', err));

// Before critical assertions
await page.screenshot({ path: `debug-${test.info().title}.png` });
console.log('Current URL:', page.url());
console.log('Visible elements:', await page.locator('[data-testid]').count());

7. Verify Test Environment Configuration

Objective: Ensure backend and frontend servers start correctly with test database.

Files to check:

• file:tests/e2e/playwright.config.ts - Server startup configuration
• file:tests/e2e/e2e-config.ts - Environment variables
• file:tests/e2e/global-setup.ts - Database initialization

Actions:

1. Verify DATABASE_PATH environment variable is set correctly for backend
2. Check backend server starts with test database (not production DB)
3. Confirm frontend connects to correct backend URL
4. Add health check polling before running tests

Configuration to verify:

// In playwright.config.ts webServer
{
  command: `DATABASE_PATH=${TEST_DB_PATH} uv run uvicorn codeframe.ui.server:app --port 8080`,
  url: 'http://localhost:8080/health',
  reuseExistingServer: !process.env.CI,
  timeout: 120000,
}

Execution Flow Diagram

sequenceDiagram
    participant Test as E2E Test
    participant Setup as Global Setup
    participant Backend as Backend API
    participant DB as SQLite DB
    participant Frontend as React App
    
    Setup->>DB: Initialize schema
    Setup->>DB: Seed test data
    Setup->>Backend: Start server (port 8080)
    Setup->>Frontend: Start dev server (port 3000)
    Setup->>Backend: Verify /health endpoint
    
    Test->>Frontend: Navigate to /projects/1
    Frontend->>Backend: GET /api/projects/1
    Backend->>DB: Query project data
    DB-->>Backend: Return project record
    Backend-->>Frontend: Project JSON
    
    Frontend->>Backend: GET /api/checkpoints?project_id=1
    Backend->>DB: Query checkpoints
    DB-->>Backend: Return checkpoint records
    Backend-->>Frontend: Checkpoints JSON
    
    Frontend->>Frontend: Render Dashboard
    Frontend->>Frontend: Render CheckpointList
    
    Test->>Frontend: Wait for [data-testid="checkpoint-panel"]
    Frontend-->>Test: Element visible ✅
    
    Note over Test,Frontend: If element not found, test fails ❌

Loading

Verification Steps

After implementing fixes:

1. Run single test in debug mode:

   cd tests/e2e
   npx playwright test test_checkpoint_ui.spec.ts --headed --debug

2. Check backend logs for API errors:

   # Backend should log all requests
   tail -f backend.log | grep "ERROR\|WARNING"

3. Verify seeded data in database:

   sqlite3 tests/e2e/.codeframe/state.db "SELECT COUNT(*) FROM checkpoints;"
   sqlite3 tests/e2e/.codeframe/state.db "SELECT COUNT(*) FROM token_usage;"

4. Test API endpoints manually:

   curl http://localhost:8080/api/projects/1
   curl http://localhost:8080/api/checkpoints?project_id=1
   curl http://localhost:8080/api/metrics/costs?project_id=1

5. Run full test suite:

   cd tests/e2e
   npx playwright test

Success Criteria

• All 23 failing tests pass consistently
• Tests complete within expected timeouts (30-60 seconds per test)
• No "element not found" errors in test output
• Backend APIs return data in expected format
• Frontend components render with proper data-testid attributes
• Test reports show green status for all smoke tests

Import In IDE

🤖 Prompt for AI Agents

## Observations

The E2E smoke tests are failing because the test components cannot find the expected DOM elements with `data-testid` attributes. After reviewing the codebase, I found that:

1. The frontend components (`file:web-ui/src/components/Dashboard.tsx`, `file:web-ui/src/components/checkpoints/CheckpointList.tsx`, `file:web-ui/src/components/metrics/CostDashboard.tsx`, `file:web-ui/src/components/reviews/ReviewSummary.tsx`) have the correct `data-testid` attributes
2. The test setup (`file:tests/e2e/global-setup.ts`) seeds comprehensive test data including agents, tasks, reviews, checkpoints, and metrics
3. The tests use proper wait strategies and timeout configurations

The root cause is likely that the **backend API endpoints are not returning data correctly** or the **frontend is not rendering due to API errors**, causing the tests to timeout waiting for elements that never appear.

## Approach

The implementation plan focuses on **diagnosing and fixing the API/data flow issues** that prevent the frontend components from rendering properly during E2E tests. The approach involves:

1. **Verify backend API endpoints** are returning the expected data structure
2. **Check database seeding** to ensure test data is properly inserted
3. **Add error handling and logging** to identify where the data flow breaks
4. **Fix API response issues** if data structure mismatches exist
5. **Update test assertions** to handle edge cases (empty states, loading states)

This approach addresses the symptom (failing tests) by fixing the underlying cause (API/data issues) rather than just adjusting test timeouts or selectors.

## Implementation Steps

### 1. Verify Backend API Endpoints

**Objective**: Ensure all API endpoints used by the failing tests return data in the expected format.

**Files to check**:
- `file:codeframe/ui/routers/checkpoints.py` - Checkpoint list endpoint
- `file:codeframe/ui/routers/metrics.py` - Metrics/cost endpoints  
- `file:codeframe/ui/routers/review.py` - Review findings endpoint
- `file:codeframe/ui/routers/projects.py` - Project status endpoint

**Actions**:
1. Review each router file to verify endpoint implementations match the frontend API client expectations
2. Check that response models include all required fields (e.g., `data-testid` expects specific field names)
3. Verify database queries return seeded test data correctly
4. Add logging to track API request/response flow during tests

**Key areas to verify**:
- Checkpoint list endpoint returns `checkpoints` array with `id`, `name`, `created_at`, `git_commit`, `metadata` fields
- Metrics endpoint returns `total_cost_usd`, `by_agent`, `by_model` breakdown
- Review endpoint returns `findings` array with `severity`, `category`, `file_path`, `message` fields
- Project status endpoint returns `progress`, `agents`, `tasks` data

### 2. Validate Database Seeding

**Objective**: Confirm test data is properly inserted into the SQLite database before tests run.

**Files to check**:
- `file:tests/e2e/seed-test-data.py` - Data seeding script
- `file:tests/e2e/global-setup.ts` - Test setup orchestration

**Actions**:
1. Add verification queries after seeding to confirm data exists
2. Check for SQL constraint violations or foreign key errors during seeding
3. Verify checkpoint files are created on disk (not just DB records)
4. Add debug logging to show seeded record counts

**Verification queries to add**:
```python
# After seeding, verify counts
cursor.execute("SELECT COUNT(*) FROM checkpoints WHERE project_id = ?", (project_id,))
checkpoint_count = cursor.fetchone()[0]
print(f"✅ Seeded {checkpoint_count} checkpoints")

cursor.execute("SELECT COUNT(*) FROM token_usage WHERE project_id = ?", (project_id,))
token_count = cursor.fetchone()[0]
print(f"✅ Seeded {token_count} token usage records")

cursor.execute("SELECT COUNT(*) FROM code_reviews WHERE project_id = ?", (project_id,))
review_count = cursor.fetchone()[0]
print(f"✅ Seeded {review_count} code reviews")
```

### 3. Add Frontend Error Handling

**Objective**: Improve error visibility when API calls fail during tests.

**Files to modify**:
- `file:web-ui/src/components/checkpoints/CheckpointList.tsx`
- `file:web-ui/src/components/metrics/CostDashboard.tsx`
- `file:web-ui/src/components/reviews/ReviewSummary.tsx`

**Actions**:
1. Add error state display with `data-testid="error-message"` for test visibility
2. Log API errors to browser console with request details
3. Add loading state indicators with `data-testid="loading-spinner"`
4. Ensure empty states have proper `data-testid` attributes

**Example error handling pattern**:
```typescript
// In component's useEffect or data fetching logic
try {
  const data = await fetchData();
  setData(data);
} catch (error) {
  console.error('[ComponentName] API Error:', error);
  setError(error.message);
}

// In render
{error && (
  <div data-testid="error-message" className="text-destructive">
    Error loading data: {error}
  </div>
)}
```

### 4. Fix API Response Structure Mismatches

**Objective**: Align backend response structure with frontend expectations.

**Common issues to check**:
1. **Checkpoint metadata**: Frontend expects `metadata.tasks_completed`, `metadata.agents_active`, etc.
2. **Cost breakdown**: Frontend expects `by_agent` and `by_model` arrays with specific field names
3. **Review findings**: Frontend expects `findings` array with `severity`, `category`, `recommendation` fields
4. **Task statistics**: Dashboard expects `total_tasks`, `completed_tasks`, `blocked_tasks`, `in_progress_tasks`

**Actions**:
1. Compare API response models in backend routers with TypeScript types in frontend
2. Add missing fields to backend responses
3. Rename fields if naming mismatch exists
4. Add default values for optional fields to prevent undefined errors

**Files to align**:
- Backend: `file:codeframe/ui/routers/*.py` response models
- Frontend: `file:web-ui/src/types/*.ts` type definitions
- API clients: `file:web-ui/src/api/*.ts` request/response handling

### 5. Update Test Assertions for Edge Cases

**Objective**: Make tests more resilient to timing issues and empty states.

**Files to modify**:
- `file:tests/e2e/test_checkpoint_ui.spec.ts`
- `file:tests/e2e/test_dashboard.spec.ts`
- `file:tests/e2e/test_metrics_ui.spec.ts`
- `file:tests/e2e/test_review_ui.spec.ts`

**Actions**:
1. Add explicit waits for API responses before checking DOM elements
2. Handle both data and empty state scenarios in assertions
3. Add retry logic for flaky WebSocket tests
4. Increase timeouts for slow-loading components

**Example improved assertion**:
```typescript
// Before: Assumes data exists
await expect(page.locator('[data-testid="checkpoint-list"]')).toBeVisible();

// After: Handles both data and empty state
const checkpointList = page.locator('[data-testid="checkpoint-list"]');
await checkpointList.waitFor({ state: 'visible', timeout: 15000 });

// Check for either checkpoints or empty state
const hasCheckpoints = await page.locator('[data-testid^="checkpoint-item-"]').count() > 0;
const hasEmptyState = await page.locator('[data-testid="checkpoint-empty-state"]').isVisible();
expect(hasCheckpoints || hasEmptyState).toBe(true);
```

### 6. Add Debug Logging to Tests

**Objective**: Capture diagnostic information when tests fail.

**Actions**:
1. Log API response status codes and bodies
2. Take screenshots before assertions
3. Capture browser console errors
4. Log component render states

**Example debug logging**:
```typescript
// In test beforeEach
page.on('console', msg => console.log('Browser:', msg.text()));
page.on('pageerror', err => console.error('Page error:', err));

// Before critical assertions
await page.screenshot({ path: `debug-${test.info().title}.png` });
console.log('Current URL:', page.url());
console.log('Visible elements:', await page.locator('[data-testid]').count());
```

### 7. Verify Test Environment Configuration

**Objective**: Ensure backend and frontend servers start correctly with test database.

**Files to check**:
- `file:tests/e2e/playwright.config.ts` - Server startup configuration
- `file:tests/e2e/e2e-config.ts` - Environment variables
- `file:tests/e2e/global-setup.ts` - Database initialization

**Actions**:
1. Verify `DATABASE_PATH` environment variable is set correctly for backend
2. Check backend server starts with test database (not production DB)
3. Confirm frontend connects to correct backend URL
4. Add health check polling before running tests

**Configuration to verify**:
```typescript
// In playwright.config.ts webServer
{
  command: `DATABASE_PATH=${TEST_DB_PATH} uv run uvicorn codeframe.ui.server:app --port 8080`,
  url: 'http://localhost:8080/health',
  reuseExistingServer: !process.env.CI,
  timeout: 120000,
}
```

## Execution Flow Diagram

```mermaid
sequenceDiagram
    participant Test as E2E Test
    participant Setup as Global Setup
    participant Backend as Backend API
    participant DB as SQLite DB
    participant Frontend as React App
    
    Setup->>DB: Initialize schema
    Setup->>DB: Seed test data
    Setup->>Backend: Start server (port 8080)
    Setup->>Frontend: Start dev server (port 3000)
    Setup->>Backend: Verify /health endpoint
    
    Test->>Frontend: Navigate to /projects/1
    Frontend->>Backend: GET /api/projects/1
    Backend->>DB: Query project data
    DB-->>Backend: Return project record
    Backend-->>Frontend: Project JSON
    
    Frontend->>Backend: GET /api/checkpoints?project_id=1
    Backend->>DB: Query checkpoints
    DB-->>Backend: Return checkpoint records
    Backend-->>Frontend: Checkpoints JSON
    
    Frontend->>Frontend: Render Dashboard
    Frontend->>Frontend: Render CheckpointList
    
    Test->>Frontend: Wait for [data-testid="checkpoint-panel"]
    Frontend-->>Test: Element visible ✅
    
    Note over Test,Frontend: If element not found, test fails ❌
```

## Verification Steps

After implementing fixes:

1. **Run single test in debug mode**:
   ```bash
   cd tests/e2e
   npx playwright test test_checkpoint_ui.spec.ts --headed --debug
   ```

2. **Check backend logs** for API errors:
   ```bash
   # Backend should log all requests
   tail -f backend.log | grep "ERROR\|WARNING"
   ```

3. **Verify seeded data** in database:
   ```bash
   sqlite3 tests/e2e/.codeframe/state.db "SELECT COUNT(*) FROM checkpoints;"
   sqlite3 tests/e2e/.codeframe/state.db "SELECT COUNT(*) FROM token_usage;"
   ```

4. **Test API endpoints manually**:
   ```bash
   curl http://localhost:8080/api/projects/1
   curl http://localhost:8080/api/checkpoints?project_id=1
   curl http://localhost:8080/api/metrics/costs?project_id=1
   ```

5. **Run full test suite**:
   ```bash
   cd tests/e2e
   npx playwright test
   ```

## Success Criteria

- All 23 failing tests pass consistently
- Tests complete within expected timeouts (30-60 seconds per test)
- No "element not found" errors in test output
- Backend APIs return data in expected format
- Frontend components render with proper `data-testid` attributes
- Test reports show green status for all smoke tests

---

Execution Information

Branch: main
Commit: 1169cb6

---

💡 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

---

🔗 Similar Issues

Possible Duplicates

• Fix checkpoint panel visibility - CheckpointList not rendering items #85

Related Issues

• Miscellaneous backend test failures #145
• Agent backend tests are failing - along with 2 integration test errors #144

🔗 Related PRs

#38 - fix(e2e): Improve Playwright test pass rate from 18% to 57% [merged]
#50 - feat: Implement Quality Gates Panel in Dashboard (#43) [merged]
#75 - test: Add comprehensive test coverage for quality gates components [merged]
#91 - fix(e2e): Fix API port mismatch in frontend clients and checkpoint UI test [merged]
#93 - fix(e2e): Fix dashboard and metrics tests for tab-based UI rendering [merged]

👤 Suggested Assignees

• frankbria

---

🧪 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!

[frankbria]

Closed with PR #154