In `CloudActivations::ActivateService`, there is an existing race condition that has the potential to occur in `find_or_create_self_managed_instance_activation!`. This was noted during review of [Refactor Find or Create SM Activation into Separate Service](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/11998), which refactored this behavior into a new service. From this [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/11998#note_2364852607): > **suggestion (non-blocking):** I think there's a race condition in here currently -- we check for an existing activation on line:12, but if another activation request is being made at the same time, then an activation could be created during the execution of lines:13-15. > > We could resolve this by locking the cloud activation before running this code? > > ```suggestion:-4+0 > cloud_activation.with_lock do > existing_activation = find_self_managed_instance_activation > return existing_activation if existing_activation > > self_managed_instance = find_or_create_self_managed_instance! > create_self_managed_instance_activation!(self_managed_instance) > end > ``` > > I'm noting this as non-blocking because this is existing behaviour. If you'd rather raise a follow up, that's all good too :)