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

[flowq-C]

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)

[lamongabriel]

Can confirm this is also happening to us.
Version: v1.2.3