<!--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=409777) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=409777) </details> <!--IssueSummary end--> MR: Pending ## Description Address TODOs in `ee/lib/remote_development/workspaces/reconcile/input/actual_state_calculator.rb`: ``` # TODO: https://gitlab.com/gitlab-org/gitlab/-/issues/409777 # This does not appear to be the normal STOPPING or STARTING scenario, because the progressing_reason # always remains 'NewReplicaSetAvailable' even when transitioning between Running and Stopped. ``` ``` # TODO: This appears to be the normal STOPPING scenario, because the progressing_reason always remains # 'NewReplicaSetAvailable' when transitioning between Running and Stopped. Confirm if different # handling of STOPPING status above is also necessary. # In normal usage (at least in local dev), this transition always happens so fast that this # state is never sent in a reconciliation request, even with a 1-second polling interval. # It always stopped immediately in under a second, and thus the next poll after a Stopped # request always ends up with spec_replicas == 0 && status_available_replicas == 0 and # matches the STOPPED state above. ``` ``` # TODO: This appears to be the normal STARTING scenario, because the progressing_reason always remains # 'NewReplicaSetAvailable' and available_reason is either 'MinimumReplicasAvailable' or # 'MinimumReplicasUnavailable' when transitioning between Stopped and Running. Confirm if different # handling of STARTING status above is also necessary. ``` ``` # TODO: This is unreachable by any of the currently implemented fixture scenarios, because it matches the # normal behavior when transioning between Stopped and Running. We need to determine what # a failure scenario actually looks like and how it differs, if at all, from a normal STARTING # scenario. Logic is commented out to avoid undercoverage failure. See related TODOs above. ``` ## Acceptance Criteria TODO: Fill out (required) - [ ] All TODOs mentioned above should be resolved, either by changing the logic, or adding an appropriate explanatory comment. <!-- 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 -->