Self-Managed Instance Activations created even when the activation fails
Bug
Summary
Trying to resend a CL activation code sometimes fails with the error there is an activated instance already
as seen in this screenshot:
However, sometimes we need to resend a cloud activation code to a new recipient and the activated instance info may not be correct.
See also details in The ActivateService sets activated_at timestamp... (#4031 - closed), where this was first identified.
Steps to reproduce
- Buy a SM subscription
- Activate an instance with >10% more seats than the subscription so that it fails
- Notice that a
Self Managed Instance Activations
entry is created in the Admin'sCloud activations
list yet the activation failed - Try to resend the CL activation code
What is the current bug behavior?
Self Managed Instance Activations
exists yet activation failed.
- As a result, CL activation code cannot be resent.
What is the expected correct behavior?
Self Managed Instance Activations
should exist only when activation on the instance succeeds.
Relevant logs and/or screenshots
This line throws the error when trying to resend the activation code, which checks activated_at
value to be set.
However we handle setting activated_at
field for the SelfManageInstanceActivation
and the creation of the seat_link
response in a transaction before the license key is sent to the GitLab instance, where the license validation can fail because of billable users/true-ups mismatch. And we do not do anything to rollback the activated_at
record.
Workarounds
A customer can get the CL activation code from CustomersDot by logging in. This would not apply for reseller customers, yet!
Reported examples
- https://gitlab.zendesk.com/agent/tickets/348598
- https://gitlab.zendesk.com/agent/tickets/349804
- https://gitlab.zendesk.com/agent/tickets/358639
Proposed solution
Set the activated_at
timestamp only if the seat link creation was successful. Despite the transaction, there is no rollback if the seat link response was unsuccessful, which means the activated_at
timestamp will stay updated no matter what the seat link response is.
This will track activations accurately and allow for resending an activation code if activation is unsuccessful. As a follow-up issue, #5530 (closed) will provide the ability to resend an activation code given any current state of the activation.
Support Priority Score: (1, 0, 0, 2, 0, 0, 0, 0, 3, 0, 0) => 6