## Problem When concurrent requests attempt to create resources (projects, groups, namespaces, etc.) with the same name/path, users receive raw PostgreSQL error messages instead of user-friendly validation errors: ```json {"message":{"base":["PG::UniqueViolation: ERROR: duplicate key value violates unique constraint \"index_namespaces_name_parent_id_type\"\nDETAIL: Key (name, parent_id, type)=(name2-12, 1, Project) already exists.\n"]}} ``` In non-concurrent scenarios, the validation catches the duplicate and returns a user-friendly error: ```json {"path":["has already been taken"]} ``` ## Root Cause A race condition occurs when the second request executes before the first resource is committed to the database. Even though the initial validation checks pass (no resource with that name exists), the database constraint is violated when both requests attempt to insert simultaneously. ## Current UX Issues - Exposes raw PostgreSQL error details (constraint names, internal key structure) - Uses technical jargon ("unique constraint", "parent_id", "type") - Not actionable for end users - Inconsistent with GitLab's validation error patterns ## Scope This issue affects multiple endpoints that create records with unique constraints: - `POST /api/v4/projects` - `POST /api/v4/groups` - Project import endpoints - Likely other endpoints with similar unique constraints ## Suggested Solution Catch `PG::UniqueViolation` errors and convert them to user-friendly validation messages that match GitLab's standard error format, similar to how validation errors are currently handled.