Better solution for determining duplicate requests
Problem
In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/8304+, a security weakness was found that allowed a subscription creation request from GitLab.com to be repeated with an adjustment to the selected_group
parameter, which lead to an existing subscription to be transferred to another namespace. This bug was addressed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/9011, but there is probably room for improvement as noted in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/9011#note_1794326417.
The idempotency_key
parameter sent from the GL.com request to CustomersDot, then used in the Zuora request, helps to prevent duplicate requests from creating duplicate resources in Zuora Billing. However, when a request with the idempotency_key
is a duplicate, the response from Zuora is identical to the original including response code. There doesn't appear to be a way to determine if the request was a duplicate from the response. This led to this less than ideal solution.
Proposal
Let consider other alternatives for ignoring duplicate requests.
Possibilities:
- Implement our own idempotent request functionality using cache
- We were able to remove
gl_namespace_id
as a permitted parameter when updating from thePurchaseService
. Is there a way to remove this parameter for the create workflow conditionally for duplicate requests?
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/9011
Follow-up fromThe following discussion from !9011 should be addressed:
-
@aish.sub started a discussion: (+2 comments) thought:
I'm not opposed to this approach, however I wonder if it might help to handle this as a 'duplicate request' upstream (at the API level).
The reason I say this is- if we add any other logic to CreateService based on whether
upsert_internal_objects
succeeded, we may end up performing the action because this service would return a success. We are in a way already having to handle this separately in create and update workflow for example.In other words, if a duplicate request is not expected, I wonder if flagging it earlier could be a possibility instead of handling it in each service. Especially given the complexity of the subscription create and update API related services.
We can also improve this in a future iteration given the current solution addresses the problem we are currently encountering with namespace change.