API DELETE /states/ returns 204 but does not delete custom states

Bug Description

Custom states created via the API cannot be deleted — neither through the API nor through the UI. The DELETE endpoint returns HTTP 204 (success) but the state remains. Attempting to delete the same custom state through the Plane UI (Project Settings → States) also fails silently — there is no delete option or it has no effect.

This rules out "API limitation" as an explanation. If custom states cannot be deleted through any interface, this is a data integrity issue.

Steps to Reproduce

Via API

1. Create a custom state via API:

curl -X POST "https://<plane-instance>/api/v1/workspaces/<ws>/projects/<pid>/states/" \
  -H "X-API-Key: <key>" \
  -H "Content-Type: application/json" \
  -d '{"name": "TEST-STATE", "group": "backlog", "color": "#888888"}'
# Returns 200 with state ID

2. Delete the state via API:

curl -X DELETE "https://<plane-instance>/api/v1/workspaces/<ws>/projects/<pid>/states/<state-id>/" \
  -H "X-API-Key: <key>"
# Returns 204 No Content — but state is NOT deleted

3. List states again — state is still present.

Via UI

4. Go to Project Settings → States
5. Attempt to delete the custom state (no issues assigned to it)
6. State cannot be removed — no delete action available or action has no effect

Workaround

The only way to remove the orphaned state is a direct database DELETE:

DELETE FROM states WHERE id = '<state-id>';

This works without foreign key violations (when no issues reference the state), confirming the state is safe to delete — the application just refuses to do it.

Expected Behavior

• Custom states with 0 assigned issues should be deletable via UI and API
• API DELETE should actually remove the state, OR return an error (409/422) explaining why deletion is not possible
• Returning 204 without deleting violates HTTP semantics (RFC 9110 §9.3.5)

Actual Behavior

• API returns 204 (implying success) but does not delete
• UI provides no working delete mechanism for custom states
• Custom states become permanent, polluting the project
• Only workaround is direct database manipulation

Impact

• Custom states created during testing, automation, or by mistake cannot be cleaned up
• Projects accumulate orphaned states with no way to remove them
• Self-hosted users can work around this via DB access, but cloud users are stuck permanently

Environment

• Plane: Self-hosted (Docker Compose)
• API: v1
• Version: Latest stable (as of 2026-03-22)

Start by reproducing the DELETE request for a custom state, then inspect the API endpoint and the Project Settings → States UI described in the issue. Verify what happens when the state has no assigned issues and compare it with the direct database deletion. Done means the state is removed through the API and UI, or either path returns a clear deletion error instead of 204 without a change.