BUG with the PUT method on the cart items api while trying to update the metadata list prop

[danielmariz]

Hi team, I'm getting a weird issue while trying to update a product variant metadata but this occurs only on the second product variant added to the cart.
My scenario requires to send a custom metadata for a single variant so I'm using the PUT method to update when a client add a new option for the same variant

When adding the first product variant to the cart everything works fine:

1. cart is empty as you can see in the api response
   
2. now I added the first item via post method
   
3. the payload is sent correctly
   
4. and the response is also as expected, so it added an item with the metadata
   
5. now I'm adding a new item to the same variant on a PUT method for the item id
   
6. the payload is sent as documented using the $set object to override the whole metadata list
   
7. the response is also correct the metadata it's being updated as expected
   
8. now I'm gonna add a new product, the new product is also added using the POST method on the cart api
   
9. the payload on the post method does not use the $set attribute
   
10. the response is correct with a new item id on the cart and correct metadata
    
11. now I'm adding a new metadata item for the same variant using the item id, it uses the PUT method

12. the payload is sent using the $set prop again

13. but the response does not change the metadata but changes the quantity

So in resume, the same calls with different behaviour from the api, I believe that using metadata like that is not a common pattern for you so you never caught this scenario before but is a requirement from my client because they don't want to treat sizes as a variant because will be more than 30 sizes combined with other 4 variant types and will be hard to manage the product content and prices. The issue only happens after the second product variant is added to the cart although I'm managing the first item with the same calls

[logeshswell]

From my understanding, the issue is PUT method on the cart items API is not updating metadata values correctly for the second cart item.

the payload is sent using the $set prop again

Can you share the correct screenshot of the request payload sent in Step-10?

[danielmariz]

From my understanding, the issue is PUT method on the cart items API is not updating metadata values correctly for the second cart item.

the payload is sent using the $set prop again

Can you share the correct screenshot of the request payload sent in Step-10?

I believe you are asking about the step-11 which was duplicated from step-10 now I updated the screenshots from step-11 simulating updating the metadata for a second variant added in the cart. So the first variant works fine with the same approach and from the second variant the issue start to happen

[logeshswell]

Can you try passing the request payload as follows for the PUT method?

{
  "$set": {
    "metadata": {
      "sizes": []
    }
  }
}

It is not highly recommended to pass $set field in the middle of the payload.

[danielmariz]

Can you try passing the request payload as follows for the PUT method?

{
  "$set": {
    "metadata": {
      "sizes": []
    }
  }
}

It is not highly recommended to pass $set field in the middle of the payload.

I've tried this approach but the docs seems to be outdate according to this comment

When trying as suggested I get a response error

I believe the issue is in the api itself, we might need to get the swell api team involved as well

[logeshswell]

Sorry, I was wrong with the request payload structure as I didn't notice that it's a frontend API.
Can you try passing the request payload as follows?

{
  "metadata": {
    "$set": {
      "sizes": []
    }
  }
}

I will also ensure my team to update the documentation:
https://developers.swell.is/frontend-api/carts#update-cart-metadata

[danielmariz]

Sorry, I was wrong with the request payload structure as I didn't notice that it's a frontend API. Can you try passing the request payload as follows?

{
  "metadata": {
    "$set": {
      "sizes": []
    }
  }
}

I will also ensure my team to update the documentation: https://developers.swell.is/frontend-api/carts#update-cart-metadata

the way you're suggesting also has issues

1. the first call for the variant is a POST on cart items api with the payload you suggested

2. the response for that returns the payload as expected

3. the second call for the same variant is a PUT on the cart item id api with the payload updating the sizes

4. the response for it changes the metadata shape so not consistent and hard to predict

so if you check the metadata object in the first call it returns sizes as a metadata property, but the second (update) puts the sizes inside an inner object with a key 0

When I tried to wrap the whole metadata object in the $set format than I could get it updated when adding items to the sizes array but not when removing an item, in that case the quantity changes but the sizes returns the removed index anyways. So still the api inconsistent

:/

[danielmariz]

The swell team needs to investigate this scenario when updating an item metadata containing a list by adding and removing items from this list from multiple variants in the cart items

[logeshswell]

I am investigating this issue and will help you with the examples of adding and removing items from the metadata list field.

[logeshswell]

I can also reproduce this issue in my store and I can confirm that it is a bug.
We'll take a deeper look at this issue and get back to you if I get some updates.

[logeshswell]

@danielmariz Just for your information, the way you updated metadata.sizes field in the PUT request is correct as per your ticket description.

You can ignore the alternate suggestions provided by me about the usage of $set.

[danielmariz]

Hi @logeshswell is there any plans for this fix in the short term? We're expecting on shipping to production soon so we might need to refactor on our side in order to make it work for us. Cheers!

[logeshswell]

This issue has already been prioritized and is yet to be worked on. I don't have an ETA, but I will keep you posted if I get any updates.