POSTing to update cart endpoint returns wrong data

[billythekid]

Description

When I post an AJAX qty update to commerce/cart/update-cart for a lineItem where the limit has been reached (i.e 1 in stock but updated qty to 2) the lineItem error is returned as expected, however the lineItem in the cart object is returned with a qty of 2 and all totals etc updated too, as if the qty update actually went through. I think this is supposed to return the cart JSON as it actually stands?

When this fails any other updates to the line item (options/note etc) are also reflected in the response but not actually saved.

Steps to reproduce

1. POST an AJAX update to the update endpoint increasing the qty past what's in stock for a non-unlimited product.

[lukeholder]

@billythekid What would you expect the behavior to be?

Commerce 2 does behave differently than commerce 1, in that the whole update request either succeeds or fails - there is no partial updating success.

[AugustMiller]

I believe this is actually the case for regular submissions, too (not just via AJAX)—the template is rendered with whatever the final in-memory state of the order is, not a fresh copy from the database, in part because it'd be a major undertaking to pluck errors off of one element and apply them piecemeal to a fresh copy. There may also be errors on non-persisted records (like new LineItems).

Admittedly, it can be a bit confusing, especially when the cart and totals appear to have been updated, in a template—but for most order-related data, it's important that the most recent (attempted) state is reflected back to you. Consider what would happen if we (for example) restored the previous state of the billing address, but displayed errors for a malformed or incomplete submission displayed next to the fields?

You should have errors attached directly to your LineItem objects, when the quantity is an issue—it might be worth displaying a bit of micro-copy, or highlighting the offending line items, etc. so as to direct the customer's attention.

This maintained state ends up being pretty important, so as to guarantee no data is lost when only one part of the request fails.

My 2¢! Hope this helps provide some context for the design decision.

[billythekid]

Thanks for the explanations all. @lukeholder I guess I expected it to be the state of the cart as it is, not what you want it to be. So if it fails on any point I'd expect the returned cart object to be in it's actual, failed and unaltered state.

I guess it might be safer then for me to ignore the cart part of the response and query the actual cart after each update, errors or not. I'm happy for the maintained state to exist and the cart.errors

Not looking for partial validations to run here, an all or nothing success or fail is cool, I just presumed the cart object we receive along with the errors would be the actual cart we have, not the cart we tried to get.

I guess I just need to get my head around why I want a cart returned that doesn't exist really. No doubt that part of the project is coming up and would have bitten me had I not started this!

Thanks again.

[edit] I see that the cart.lineItems don't have their errors applied on a per-item basis(just the cart.errors) with the AJAX version but do on the regular page-load version. Is this something that could be added to the AJAX response?

[lukeholder]

Added the errors array to the cart ajax response.

You can now also retrieve the current good (last saved) representation of the cart with an ajax GET request to the commerce/cart/get-cart controller action.

Will be in the next release unless you are running off dev-develop

[soerenmeier]

Just came here because i also expected the database state to be returned. Would you consider adding a flag to get the db state of the cart instead of the wanted state? Or do i need to do a separate request?

[lukeholder]

@soerenmeier I just added an originalCart value to the update cart failure response for the next major release of commerce. Will update this issue once that is available.

[soerenmeier]

Nice, thanks