Skip to content

Preserve idempotency key for purchase pages' form states

Mohamed Moustafa requested to merge mtimoustafa/cdot-7496-stateful-idempontency-key into master

What does this MR do and why?

Resolves https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/7496+.

Recently, we introduced an idempotency key to purchase pages that's sent along with purchase confirmation requests to the backend. We caught an edge case where after a failed purchase request, a user can change some form input then change them back to their original values, regenerating the idempotency key, then submitting the request again. This violates the mechanism where the idempotency key must remain the same between failed requests, so we don't duplicate subscription purchases.

This MR adds state tracking for idempotency keys, where we use the same key for the same set of form input.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Case Screen Recording
Idempotency key is stored according to form fields' state key_regeneration
Successful purchase sends correct idempotency key successful_purchase
Card with insufficient funds does not regenerate idempotency key card_with_insufficient_funds
4xx error returned regenerates idempotency key 422_error
Non-4xx error returned does not regenerate idempotency key 500_error

How to set up and validate locally

  1. Start GDK and CustomersDot.

  2. Perform the following steps for the Subscription and Add-On purchase pages:

    1. Fill out the form, open your devtools' network tab, and click "Buy subscription".
    2. Check that the request POST /subscriptions contains an idempotency_key parameter in the body. Note the key value.
    3. Change a value in the form (e.g. quantity or purchase method), change it back to its original value, and click "Buy subscription" again.
    4. Check that the new POST request contains the same value for idempotency_key.

For testing the 4xx and non-4xx error states, please refer to the error scenarios in this MR.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports