Description
Summary
Currently it seems that when using the addProductsToCart mutations in GraphQL if one product is out of stock, it will reject the whole request. Based on our developers' feedback this makes them resort to adding items to the cart one by one instead of using the mass endpoint because:
- it will take longer to respond and not actually add items to the cart (performance)
- it will only provide one failed sku in the response even if there are more out of stock products than 1 so it can potentially need the same requests as adding one by one but they are slower
- it's not intuitive
Examples
Think of the reorder case. I would like to reorder my previously purchased items.
What's expected is that we can add them all in one sweep if possible for every single product type.
For example
Problem Statement
When attempting to add multiple products to the shopping cart in a single request, there's a chance that some products may not be available (out-of-stock, for instance). For every failed product, the entire request needs to be retried with one fewer product. This leads to extra requests, increasing server load and reducing performance.
Example Scenario
Let's consider you want to add 5 products: [prod1, prod2, prod3, prod4, prod5]. Two of them, prod2 and prod4, are not in stock.
First Request: Attempt to add 5 products.
- Products to add: [prod1, prod2, prod3, prod4, prod5]
- Failed: [prod2, prod4]
- Successful: None
Second Request: Remove prod2, and retry with 4 products.
- Products to add: [prod1, prod3, prod4, prod5]
- Failed: [prod4]
- Successful: None
Third Request: Remove prod4, and retry with 3 products.
- Products to add: [prod1, prod3, prod5]
- Failed: None
- Successful: [prod1, prod3, prod5]
Proposed solution
Solution 1
List all problematic products in one response. Then the user only needs one additional request to add the products to cart
Solution 2
Add the correct products, notify about the failed ones. The user doesn't need additional requests.
Release note
No response
Triage and priority
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.