Redesign database error handling test for project creation API

[frankbria]

Problem

The test test_create_project_handles_database_errors in tests/api/test_project_creation_api.py:215 is currently skipped with the reason:

Database close() creates ungraceful crashes, not 500 errors. This test design is flawed.

Current State

The test attempts to verify that database errors are handled gracefully by the project creation API endpoint and return proper 500 Internal Server Error responses. However, the current approach of forcibly closing the database connection causes ungraceful crashes instead of testable error conditions.

Proposed Solution

Redesign this test to properly validate database error handling:

1. Mock database operations: Instead of closing the database, use mocking to simulate database errors (e.g., sqlite3.OperationalError, sqlite3.IntegrityError)
2. Test specific error scenarios:
   • Disk full error
   • Database locked error
   • Constraint violation error
3. Verify proper error responses: Ensure the API returns 500 status code with appropriate error messages
4. Add error logging validation: Verify that errors are properly logged for debugging

Acceptance Criteria

• Test no longer uses db.close() to trigger errors
• Test uses mocking or dependency injection to simulate database failures
• Test verifies 500 status code is returned
• Test verifies error response contains meaningful message
• Test passes consistently in CI/CD pipeline
• Skip decorator is removed

File Location

tests/api/test_project_creation_api.py:215-221

[traycerai]

Plan

Observations

The skipped test at file:tests/api/test_project_creation_api.py:215-221 attempts to verify database error handling by closing the database connection, which causes ungraceful crashes. The project creation endpoint at file:codeframe/ui/server.py:311-373 calls app.state.db.create_project() and has a try-except block that catches workspace creation failures but doesn't explicitly test database operation failures. The codebase uses pytest without pytest-mock, but unittest.mock from Python's standard library is available. Other tests in the codebase use direct database operations and pytest.raises(Exception) for error testing.

Approach

The test will be redesigned to use unittest.mock.patch to mock the database's create_project() method to raise various SQLite exceptions (sqlite3.OperationalError, sqlite3.IntegrityError). This approach simulates realistic database failures without causing crashes. The test will verify that the API endpoint returns a 500 status code with appropriate error messages, ensuring graceful error handling. This aligns with the existing error handling pattern in the endpoint's try-except block and follows the codebase's testing conventions.

Implementation Steps

1. Update Test Structure

File: file:tests/api/test_project_creation_api.py

Remove the @pytest.mark.skip decorator from test_create_project_handles_database_errors at line 215. Replace the single skipped test with multiple specific test methods to cover different database error scenarios.

2. Implement Database Locked Error Test

Create a new test method test_create_project_database_locked_error that:

• Uses unittest.mock.patch to mock app.state.db.create_project
• Configures the mock to raise sqlite3.OperationalError("database is locked")
• Makes a POST request to /api/projects with valid project data
• Asserts response status code is 500
• Asserts response JSON contains a "detail" field with error information
• Verifies the error message indicates a database operation failure

3. Implement Disk Full Error Test

Create a new test method test_create_project_disk_full_error that:

• Uses unittest.mock.patch to mock app.state.db.create_project
• Configures the mock to raise sqlite3.OperationalError("disk I/O error")
• Makes a POST request to /api/projects with valid project data
• Asserts response status code is 500
• Asserts response contains appropriate error details

4. Implement Constraint Violation Error Test

Create a new test method test_create_project_integrity_error that:

• Uses unittest.mock.patch to mock app.state.db.create_project
• Configures the mock to raise sqlite3.IntegrityError("UNIQUE constraint failed")
• Makes a POST request to /api/projects with valid project data
• Asserts response status code is 500
• Asserts response contains appropriate error details

5. Verify Error Handling in API Endpoint

File: file:codeframe/ui/server.py

Review the create_project endpoint (lines 311-373) to ensure it properly catches database exceptions. The current implementation has a try-except block for workspace creation failures (lines 358-361). Verify that database exceptions from app.state.db.create_project() (line 335) are either:

• Already caught by an outer exception handler
• Need an additional try-except block around the database call

If needed, wrap the app.state.db.create_project() call in a try-except block that catches sqlite3.Error and raises HTTPException(status_code=500, detail=f"Database error: {str(e)}").

6. Test Implementation Pattern

Each test should follow this structure:

import sqlite3
from unittest.mock import patch

def test_create_project_<error_type>(self, api_client):
    """Test that <specific error> returns 500 Internal Server Error."""
    with patch('codeframe.ui.server.app.state.db.create_project') as mock_create:
        mock_create.side_effect = sqlite3.<ErrorType>("<error message>")
        
        response = api_client.post(
            "/api/projects",
            json={"name": "test-project", "description": "Test"}
        )
        
        assert response.status_code == 500
        data = response.json()
        assert "detail" in data
        assert "<expected_keyword>" in data["detail"].lower()

7. Import Required Modules

At the top of file:tests/api/test_project_creation_api.py, add:

• import sqlite3 (for exception types)
• from unittest.mock import patch (for mocking)

8. Organize Tests in Test Class

Keep all database error handling tests within the TestProjectCreationErrorHandling class (starting at line 212). This maintains the existing test organization structure.

9. Verification Checklist

After implementation, verify:

• All three new test methods pass consistently
• Tests properly mock the database method without affecting other tests
• The @pytest.mark.skip decorator is removed
• Response status codes are 500 for all database errors
• Response bodies contain meaningful error messages
• Tests run in isolation without side effects
• The api_client fixture's class-scoped nature doesn't interfere with mocking

Test Execution Flow

sequenceDiagram
    participant Test as Test Method
    participant Mock as unittest.mock.patch
    participant API as FastAPI Endpoint
    participant DB as Database (Mocked)
    
    Test->>Mock: patch('app.state.db.create_project')
    Test->>Mock: Configure side_effect = sqlite3.Error
    Test->>API: POST /api/projects
    API->>DB: create_project(...)
    DB-->>API: Raise sqlite3.Error
    API->>API: Catch exception
    API-->>Test: HTTPException(500, detail="...")
    Test->>Test: Assert status_code == 500
    Test->>Test: Assert error message present

Loading

Error Scenarios Coverage

Error Type	SQLite Exception	Test Method	Expected Behavior
Database Locked	sqlite3.OperationalError	test_create_project_database_locked_error	500 with "database" in error
Disk I/O Error	sqlite3.OperationalError	test_create_project_disk_full_error	500 with "database" or "I/O" in error
Constraint Violation	sqlite3.IntegrityError	test_create_project_integrity_error	500 with "database" or "constraint" in error

Import In IDE

🤖 Prompt for AI Agents

## Observations

The skipped test at `file:tests/api/test_project_creation_api.py:215-221` attempts to verify database error handling by closing the database connection, which causes ungraceful crashes. The project creation endpoint at `file:codeframe/ui/server.py:311-373` calls `app.state.db.create_project()` and has a try-except block that catches workspace creation failures but doesn't explicitly test database operation failures. The codebase uses pytest without pytest-mock, but `unittest.mock` from Python's standard library is available. Other tests in the codebase use direct database operations and `pytest.raises(Exception)` for error testing.

## Approach

The test will be redesigned to use `unittest.mock.patch` to mock the database's `create_project()` method to raise various SQLite exceptions (`sqlite3.OperationalError`, `sqlite3.IntegrityError`). This approach simulates realistic database failures without causing crashes. The test will verify that the API endpoint returns a 500 status code with appropriate error messages, ensuring graceful error handling. This aligns with the existing error handling pattern in the endpoint's try-except block and follows the codebase's testing conventions.

## Implementation Steps

### 1. Update Test Structure

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

Remove the `@pytest.mark.skip` decorator from `test_create_project_handles_database_errors` at line 215. Replace the single skipped test with multiple specific test methods to cover different database error scenarios.

### 2. Implement Database Locked Error Test

Create a new test method `test_create_project_database_locked_error` that:
- Uses `unittest.mock.patch` to mock `app.state.db.create_project`
- Configures the mock to raise `sqlite3.OperationalError("database is locked")`
- Makes a POST request to `/api/projects` with valid project data
- Asserts response status code is 500
- Asserts response JSON contains a "detail" field with error information
- Verifies the error message indicates a database operation failure

### 3. Implement Disk Full Error Test

Create a new test method `test_create_project_disk_full_error` that:
- Uses `unittest.mock.patch` to mock `app.state.db.create_project`
- Configures the mock to raise `sqlite3.OperationalError("disk I/O error")`
- Makes a POST request to `/api/projects` with valid project data
- Asserts response status code is 500
- Asserts response contains appropriate error details

### 4. Implement Constraint Violation Error Test

Create a new test method `test_create_project_integrity_error` that:
- Uses `unittest.mock.patch` to mock `app.state.db.create_project`
- Configures the mock to raise `sqlite3.IntegrityError("UNIQUE constraint failed")`
- Makes a POST request to `/api/projects` with valid project data
- Asserts response status code is 500
- Asserts response contains appropriate error details

### 5. Verify Error Handling in API Endpoint

**File:** `file:codeframe/ui/server.py`

Review the `create_project` endpoint (lines 311-373) to ensure it properly catches database exceptions. The current implementation has a try-except block for workspace creation failures (lines 358-361). Verify that database exceptions from `app.state.db.create_project()` (line 335) are either:
- Already caught by an outer exception handler
- Need an additional try-except block around the database call

If needed, wrap the `app.state.db.create_project()` call in a try-except block that catches `sqlite3.Error` and raises `HTTPException(status_code=500, detail=f"Database error: {str(e)}")`.

### 6. Test Implementation Pattern

Each test should follow this structure:

```python
import sqlite3
from unittest.mock import patch

def test_create_project_<error_type>(self, api_client):
    """Test that <specific error> returns 500 Internal Server Error."""
    with patch('codeframe.ui.server.app.state.db.create_project') as mock_create:
        mock_create.side_effect = sqlite3.<ErrorType>("<error message>")
        
        response = api_client.post(
            "/api/projects",
            json={"name": "test-project", "description": "Test"}
        )
        
        assert response.status_code == 500
        data = response.json()
        assert "detail" in data
        assert "<expected_keyword>" in data["detail"].lower()
```

### 7. Import Required Modules

At the top of `file:tests/api/test_project_creation_api.py`, add:
- `import sqlite3` (for exception types)
- `from unittest.mock import patch` (for mocking)

### 8. Organize Tests in Test Class

Keep all database error handling tests within the `TestProjectCreationErrorHandling` class (starting at line 212). This maintains the existing test organization structure.

### 9. Verification Checklist

After implementation, verify:
- All three new test methods pass consistently
- Tests properly mock the database method without affecting other tests
- The `@pytest.mark.skip` decorator is removed
- Response status codes are 500 for all database errors
- Response bodies contain meaningful error messages
- Tests run in isolation without side effects
- The `api_client` fixture's class-scoped nature doesn't interfere with mocking

## Test Execution Flow

```mermaid
sequenceDiagram
    participant Test as Test Method
    participant Mock as unittest.mock.patch
    participant API as FastAPI Endpoint
    participant DB as Database (Mocked)
    
    Test->>Mock: patch('app.state.db.create_project')
    Test->>Mock: Configure side_effect = sqlite3.Error
    Test->>API: POST /api/projects
    API->>DB: create_project(...)
    DB-->>API: Raise sqlite3.Error
    API->>API: Catch exception
    API-->>Test: HTTPException(500, detail="...")
    Test->>Test: Assert status_code == 500
    Test->>Test: Assert error message present
```

## Error Scenarios Coverage

| Error Type | SQLite Exception | Test Method | Expected Behavior |
|------------|-----------------|-------------|-------------------|
| Database Locked | `sqlite3.OperationalError` | `test_create_project_database_locked_error` | 500 with "database" in error |
| Disk I/O Error | `sqlite3.OperationalError` | `test_create_project_disk_full_error` | 500 with "database" or "I/O" in error |
| Constraint Violation | `sqlite3.IntegrityError` | `test_create_project_integrity_error` | 500 with "database" or "constraint" in error |

---

Execution Information

Branch: main
Commit: dbd2813

---

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

[frankbria]

Fixed with PR #79