<!--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=425249) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=425249) </details> <!--IssueSummary end--> MR: Pending <!-- The first line of the MR must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, and the first description line of the MR should be `Issue: <Issue link with trailing +>` 3. `MR: No MR` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description Update Remote Development user documentation with caveats around behavior of auto-termination of orphaned workspaces, as described in https://gitlab.com/groups/gitlab-org/-/epics/11452#note_1559480059: We need to be aware of the implications of this approach: 1. The user experience isn't great. If we leave all the associations to `CASCADE DELETE`, when the associated records are deleted, the workspace record disappears immediately from the database, UI, and everywhere. 1. This means the experience will be that the user doesn't see the workspace in the UI anymore, but the workspace will still be running and accessible for some period of time, maybe not until the next full reconcile which may be for several minutes. 1. This could be a confusing experience, so we will need to be sure to document this behavior. The docs should not be merged until the implementation is complete: https://gitlab.com/gitlab-org/gitlab/-/issues/425248+ ## Acceptance Criteria - [ ] Docs are updated to clearly describe this behavior, the scenarios in which it can occur, and set expectations <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->