<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=551912) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=551912) </details> <!--IssueSummary end--> MR: Pending ## Description Currently, existence of `workspaces` table records prevents deletion of `users` records, because the constraint is `RESTRICT` not `CASCADE`: ``` ALTER TABLE ONLY workspaces ADD CONSTRAINT fk_ec70695b2c FOREIGN KEY (personal_access_token_id) REFERENCES personal_access_tokens(id) ON DELETE RESTRICT; ``` This should get changed to `CASCADE`, in order to not block deletion/cleanup of `users` records. We realize that this might leave orphaned workspaces, but this is impossible to always enforce (e.g. if the cluster is no longer connected via the agent), so we will proceed with just deleting the workspace anyway. We can potentially look at other solutions to the orphaned workspace problem (e.g. always force-terminating orphaned workspaces in the reconciliation loop) ## References - Internal slack thread: https://gitlab.slack.com/archives/CJS40SLJE/p1750882163002439 - https://gitlab.com/gitlab-com/support/internal-requests/-/issues/26339#note_2588520960 on https://gitlab.com/gitlab-com/support/internal-requests/-/issues/26339+s ## Acceptance criteria - [ ] Migration to switch constraint as described above - [ ] Update any relevant docs. Not sure where, if there's admin docs on user deletion, that would be a good place. <!-- NOTE: Feel free to expand with more sections and headers as needed --> <!-- DO NOT TOUCH BELOW -->