<!--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> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=556143) </details> <!--IssueSummary end--> MR: Pending <!-- NOTE: For context on MR heading, see: https://handbook.gitlab.com/handbook/engineering/devops/dev/create/remote-development/index.html#relationship-of-issues-to-mrs --> ## Description gitlab-org/gitlab#553324+ presented us with a case where a workspace agent config is deleted manually from the database, but the associated workspace still exists, leading to the [following errors on Sentry:](https://new-sentry.gitlab.net/organizations/gitlab/issues/1542840/?alert_rule_id=50&alert_type=issue&notification_uuid=6e3c9ed8-f621-487a-9d80-75e7bee8d510&project=3&referrer=slack) ``` ..... RuntimeError #workspaces_agent_config cannot be called until #agent and #agent.unversioned_latest_workspaces_agent_config are set. (RuntimeError) ``` We would need a way to prevent the deletion of an agent config entry if workspaces exist for that agent. This would force any cleanup logic to first delete all workspaces before proceeding to clean up the associated agent config. We should also consider applying these deletion constraints on other workspace child records like `workspace_variables`, `user_provided_workspace_variables`, `workspace_agentk_state` and `workspace_token`, i.e do not allow deleting these records until the associated workspace is deleted. Our current proposal is to write DB-level triggers to enforce these constraints, but we should take a look at how this is done in other areas of the codebase before committing and address any spec setup rewrites that might come as a result of adding triggers (triggers may affect factories used in specs) We should also be aware of how workspace records relate to each other to prevent ending up in weird dependency chains due to adding constraints/triggers <!-- TODO: What kind of issue is this? Please uncomment and include one of the following: /label ~"type::feature" /label ~"type::bug" /label ~"type::maintenance" --> <!-- OPTIONAL: Is this a feature/enhancement? - Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole. - Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality. --> <!-- OPTIONAL: Is this a bug? Please uncomment and include the following: - **Current behavior:** - **Expected behavior:** - **Steps to reproduce:** - **Additional information:** please include VSCode version, browser dev tool logs, etc that might be helpful to debug the issue! --> ## Acceptance criteria - [ ] Come up with safe DB constraints to enforce correct deletion order of workspaces and related records ## Implementation plan <!-- NOTE: Feel free to expand with more sections and headers as needed --> <!-- DO NOT TOUCH BELOW -->