{"section":"known-issues","requestedLocale":"en","requestedSlug":"checkout-api-handle-cart-items-misbehaviors-when-sending-attachments-for-already-added-items","locale":"en","slug":"checkout-api-handle-cart-items-misbehaviors-when-sending-attachments-for-already-added-items","path":"docs/en/known-issues/Checkout/checkout-api-handle-cart-items-misbehaviors-when-sending-attachments-for-already-added-items.md","branch":"main","content":"## Summary\n\nWhen using checkout API to Handle cart items where a given item was already added without \"_attachments_\", trying to include it again, this time with \"_attachments_\", won't work correctly nor register anything.\n\nThe \"_checkout-graphql\"_ uses this API to resolve mutations, so using the \"_addToCart\"_ mutation in a cart where a given item was already added without \"_options_\", and trying to include it again with \"_options_\", won't work correctly either. The mutation won't register the sent \"_options_\" and will also return an error if they are related to \"_subscription_\" information.\n\nIn this context, the \"_options_\" property is used to declare \"_assemblyOptions_\", both for \"_composition_\" or \"_inputValues_\", which is also used in place of \"_itemAttachments_\" and to include \"_subscriptionsData_\".\n\nPresent behaviors:\n- _addToCart_ **without** sending \"_options_\" to an already added item **also without** \"_options_\" will update their quantity **to** the given number\n- _addToCart_ with or without sending \"_options_\" to an already added item **with**\"_options_\" will work to include **new**/repeated items with the given quantity\n\nWhere the issue happens:\n- _addToCart_ sending \"options\" to an already added item without \"options\"\n\nThe \"_options_\" won't be registered (neither updating nor working as a new item) on the orderForm. Still, they'll work on updating the quantity for the already added item – in the same way as the first behavior described.\n\nThe worst scenario happens if you send an \"_option_\" related to subscription information. The \"_addToCart\"_ mutation has a chained action to update the \"_subscriptionsData_\" section from the orderForm with the information from this \"_option_\", and in this case, it'll fail, returning errors for the operation – but also doing the previous action, which updates the quantity.\n\nFor the record, the mutation \"_updateItems\"_ doesn't work to add items or add/remove \"_options_\" to an already added item.\n\n## Simulation\n\nConsidering this mutation:\n\n    mutation ($orderFormId: ID, $items: [ItemInput]) \\{  addToCart(orderFormId: $orderFormId, items: $items) \\{    ...  \\}\\}\n\n\nThe first request, which works well:\n\n    \\{  \"items\": [    \\{      \"id\": 123,      \"quantity\": 1,      \"seller\": \"1\"    \\} ]\\}\n\n\nThe second request, including the same item but with subscription information:\n\n    \\{  \"items\": [    \\{      \"id\": 123,      \"index\": 0,      \"quantity\": 1,      \"seller\": \"1\",      \"options\": [        \\{          \"assemblyId\": \"vtex.subscription\",          \"inputValues\": \\{            \"vtex.subscription.key.frequency\": \"1 month\"          \\}        \\}     ]    \\}  ]\\}\n\nThe response:\n\n    \\{  \"data\": null,  \"errors\": [    \\{      \"message\": \"Request failed with status code 400\",      ...          \"response\": \\{            \"data\": \\{              \"Fields\": \\{\\},              \"operationId\": \"acdb9ef5-59dc-49a7-9d79-d3fb895d81fe\",              \"error\": \\{                \"code\": \"1\",                \"message\": \"Assinatura inválida\",                \"exception\": null              \\}            \\},            ...    \\} ]\\}\n\n## Workaround\n\nN/A"}