Improve workspace cleanup in project creation rollback

[claude]

Description

When project creation fails during workspace initialization, the API endpoint in codeframe/ui/server.py:321-324 performs a rollback by deleting the database record:

except Exception as e:
    # Cleanup: delete project if workspace creation fails
    app.state.db.delete_project(project_id)
    raise HTTPException(status_code=500, detail=f"Workspace creation failed: {str(e)}")

However, this only cleans up the database - it doesn't explicitly clean up the filesystem workspace if it was partially created.

Current Behavior

• The WorkspaceManager has cleanup logic in its exception handler (manager.py:67-69), which uses shutil.rmtree(workspace_path, ignore_errors=True)
• If the WorkspaceManager cleanup fails or is interrupted, orphaned workspace directories could accumulate
• The API endpoint doesn't verify that workspace cleanup succeeded

Proposed Solution

Add explicit workspace cleanup in the API endpoint's exception handler:

except Exception as e:
    # Cleanup: delete project and workspace if creation fails
    app.state.db.delete_project(project_id)
    
    # Explicitly clean up workspace directory if it exists
    workspace_path = Path(app.state.workspace_root) / str(project_id)
    if workspace_path.exists():
        try:
            shutil.rmtree(workspace_path)
            logger.info(f"Cleaned up orphaned workspace: {workspace_path}")
        except Exception as cleanup_error:
            logger.error(f"Failed to clean up workspace {workspace_path}: {cleanup_error}")
    
    raise HTTPException(status_code=500, detail=f"Workspace creation failed: {str(e)}")

Related

Identified in PR #6 code review - Project Schema Refactoring

[frankbria]

Status Review (2025-12-05)

Reviewed the current codebase and confirmed this issue is still valid and has not been implemented.

Current State

• API endpoint (): Only deletes database record on workspace creation failure
• WorkspaceManager (): Has cleanup logic with shutil.rmtree(workspace_path, ignore_errors=True), but this doesn't guarantee cleanup if interrupted or if the exception happens after the WorkspaceManager returns successfully

Analysis

The proposed solution is reasonable and would improve robustness by adding explicit workspace cleanup in the API endpoint's exception handler. This provides a defense-in-depth approach:

1. WorkspaceManager attempts cleanup on its own exceptions
2. API endpoint verifies and ensures cleanup as a fallback

Priority Assessment

• Severity: Low-Medium (affects resource management but not functionality)
• Impact: Orphaned workspace directories could accumulate over time
• Risk: Low if WorkspaceManager cleanup succeeds most of the time
• Recommendation: Good enhancement for production robustness, but not urgent

Suggested Implementation

The proposed solution in the issue description looks good. Additionally, consider:

• Adding a utility method to WorkspaceManager: cleanup_workspace(project_id: int) for reusability
• Logging successful vs failed cleanup attempts for monitoring
• Optionally adding a CLI command to detect and clean up orphaned workspaces

Keeping this issue open for future implementation.