Exception\OrderVersionMismatchException

Could you provide the backtrace of the exception please?

You could in the meantime, allow the order save by changing the setting to log the exception instead of throwing it from admin/commerce/config/orders/settings.

Of course the error went away since this was previously not logged... So there's no need to downgrade.

I invite you to read the "Order locking" section from https://www.centarro.io/blog/drupal-commerce-core-225-expands-payment-co....

@Lilliplanet: You're saying the error is constantly reproducible? Every time you place an order that creates a subscription?

Error: With a fresh install of Commerce version 8.x-2.28, every time you place an order with a recurring subscription, get the error Drupal\commerce_order\Exception\OrderVersionMismatchException.

I'm not sure what you mean, 2.28 doesn't exist yet? You meant 2.24 and 2.26? The error wasn't logged prior to Commerce 2.25, so that is expected...

In other words, the error has always been there, it was just "transparent" previously.

I'm not sure what the screenshot is supposed to show?

Your screenshot shows records from the commerce_order__order_items DB table, which doesn't prove anything? This table holds the order items referenced by an order.

Once again, prior to Commerce 2.25, no error was logged. So there's a high chance the error was already present, it was simply not logged anywhere.

In any event, it could be a bug in the commerce_recurring module, not commerce itself...

fwiw, tried setting up commerce + commerce recurring and stripe.

Placed an order, and didn't get this error in the logs.

I'd be great if you could provide a list of reproducible steps we can reproduce.

I'm seeing the same error with Commerce Core 8.x-2.26, but I'm not using Commerce Recurring or Stripe. The logged message doesn't include stack trace. It doesn't happen with every order, so I don't know how to reproduce it.

I've also noticed that orders associated with this error have two instances of Shipment #1. One of the shipments changes state when I change the state of the order; the other doesn't. I can delete the shipment that doesn't change state and everything seems fine after the duplicate shipment is deleted.

I'm sorry but this version thing seems half-baked and not ready at all for production. I am getting these errors after updating my Commerce setup and the ironic part is that attempting to save the order and then running into this error is causing the order to get permanently deleted in some cases--the whole point of this feature being preventing data loss. Why was the default setting the one that could potentially cause catastrophic results?

I just checked the past 3 version release notes and do not see a SINGLE mention of this feature being added. I honestly have no idea where the feature even came from. Why was this not documented, considering it's potential to cause devastating results?

post got duplicated

I just checked the past 3 version release notes and do not see a SINGLE mention of this feature being added. I honestly have no idea where the feature even came from. Why was this not documented, considering it's potential to cause devastating results?

https://www.centarro.io/blog/drupal-commerce-core-225-expands-payment-co...

The default setting should log the exception (instead of throwing it), I can't think of a reason why this would cause your order to be deleted TBH...

We've updated Commerce on several on our projects and we've never experienced anything similar...

I have the same issue with Commerce 8.x-2.26 and Commerce Authorize.net 8.x-1.3.

Drupal\commerce_order\Exception\OrderVersionMismatchException: Attempted to save order 3069 with version 28. Current version is 29. in Drupal\commerce_order\Entity\Order->preSave() (line 660 of /web/modules/contrib/commerce/modules/order/src/Entity/Order.php).

The exception is logged on every order and some orders get duplicate Shippment #1 with different state (attached screenshot). Didn't notice any data loss.

When testing with Manual payment gateway there is no exception, only with Authorize.net both sandbox and live. Not using Commerce Recurring.

I might be wrong with this being the only contributor to causing an order to be deleted but what I saw in the logs was the OrderVersionMismatchException error message as the last error for the order, with the Order entity being completed deleted. It wasn't a clean ->delete(), there were still tons of references to that Order ID on the order_items tables and the custom field tables. I should mention that most of my customizations are within the ecosystem but there are some custom hook_form_alters() or other things that we have to patch certain functionality since we've been on Commerce for over 4 years now. However, I don't have anything that deletes an order on my end.

EDIT: If you want to skip this tl;dr stuff, I have steps on recreating the issue below:

I've done some deeper digging and found 1 cause of issue on my site on the Order Information page. In ShippingInformation.php, the if statement on Line 342 looks like this:

    if (!$this->hasRateSelected($pane_form, $form_state)) {
      array_map(function (ShipmentInterface $shipment) {
        if (!$shipment->isNew()) {
          $shipment->save();
        }
      }, $shipments);
      $this->order->set('shipments', $shipments);
      $this->order->save();
    }

However, this means that it attempts to save the order whenever ShippingInformation gets rebuilt and there is no shipment selected. The buildPaneForm gets called on any ajax call that rebuilds the checkout form. This happens often with anonymous users who have not yet entered in their address and thus have no shipment selected, causing this if statement to be true and then causing an unnecessary save. So what seems to be happening here is that when a coupon is entered, it saves the order once from that and then the rebuilding of the checkout form also causes a second order save ShippingInformation. I believe this was added in the most recent commerce_shipping to auto update the order summary with your shipping selection.

Therefore, I updated the if statement line with this:

if (!$this->hasRateSelected($pane_form, $form_state) && !empty($shipments)) {

That prevents an extra save if a rate is selected by default or already existed and prevents ShippingInformation.php from saving an empty $shipments variable and potentially causing double saves.

To recreate the issue:

1. For checkout flow, make sure OrderInformation and CouponRedemption are on the same page. Ensure order type is shippable. Create promotion for any amount and setup so that it should apply to your order.
2. Shop as anonymous user. Add item to cart. Go to Order information page
3. Do not add shipping address yet. Attempt to add a coupon and it will fail. It may add an Exception into your log for the version exception
4. A second attempt to add the coupon will work for some reason, which I'm not sure why
5. If you don't add an address and you remove the coupon (if you try a second time), you can refresh the page and recreate the issue over and over

I cannot get the version mismatch exception to occur locally. Yet if I follow these steps on production, it ALWAYS creates a version exception (currently my site is set to ignore them but it still causes an issue with the Coupon form). Not sure why that would be happening but the issues with the coupon form happen nonetheless, whether the exception gets thrown or not.

After adding that line, I'm no longer seeing errors in production. If anyone is interested, here is a patch--it is patched against "drupal/commerce_shipping" and not "drupal/commerce".

Sorry, here is the same patch, but renamed for the contrib guidelines on patch naming.

@cchoe1: Could you please create an issue and post your patch in the Commerce shipping queue? This patch doesn't belong to this queue.

Sure I'll create a new issue over there. But it does result in this OrderVersionMismatchException so I thought it would make sense to at least bring it up here as well.

Edit: here is the new issue in case anyone wants to view what's being said over there

https://www.drupal.org/project/commerce_shipping/issues/3231138

This was fixed in Commerce shipping.

I am getting this issue on commerce 2.36

Drupal\commerce_order\Exception\OrderVersionMismatchException: Attempted to save order 56 with version 6. Current version is 7. in Drupal\commerce_order\Entity\Order->preSave() (line 681 of /app/web/modules/contrib/commerce/modules/order/src/Entity/Order.php).

@nicxvan: Reopening a 2 years old issue isn't going to help.
You'd need to figure out what's causing this on your installation... This could be due to many different reasons, race conditions, badly written code... Without reproducible steps, a backtrace or anything else we can exploit, simply copy/pasting this error message isn't helping in any way.

Also, in case you'd like to report a bug, open a new issue, but please make sure to provide something we can work with.

Sorry I was going to open a new issue but thought some context from this would be helpful. I was trying to reproduce it and couldn't so I didn't add additional info.
I also ended up tracking down a few separate issues. Happy to open a new issue if it comes up again.

@jsacksick the exact same error is appearing for me as well.
Drupal\commerce_order\Exception\OrderVersionMismatchException: Attempted to save order 3973 with version 7. Current version is 8. in Drupal\commerce_order\Entity\Order->preSave() (line 681 of /home/mysite/public_html/modules/contrib/commerce/modules/order/src/Entity/Order.php).

There are no other backtraces in the dblog for this error and the error will appear for every order saved in the shoppping cart.
I'm not sure how to reproduce it on my own. It just appears randomly.

If there's any instructions on how to cause a backtrace to appear for the next time this is triggered I would be glad to provide it for further diagnostic.

@nicxvan I am having the same issue. Please let me know if you have figured out the cause.

If you change the setting from admin/commerce/config/orders/settings to "Prevent the save and throw an exception that may cause a fatal error..", the potential data loss will be prevented but it'll cause a crash. You should be able to see what's causing this this way.

@jsacksick

Thanks I've changed the setting as suggested.
I've also tried to access various page, forms, add and remove items from cart.
But I am not able to cause this error to trigger on it's own.

Will need to observe the log and wait for the next time something to cause this error to trigger.

Thanks and happy Thanksgiving!

@jsacksick

This new error is now triggering in addition to the previous error.

Drupal\Core\Entity\EntityStorageException: Attempted to save order 3932 with version 787. Current version is 788. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of /home/mysite/public_html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Comparing the SqlContentEntityStorage.php on my server to the official core 10.1.6 release and there were some differences.
Looking to the date it would appear this particular file was edited previously. Possible from a patch.

Using the official core release version now to verify if problem persists.

Will report back. Thanks.

After correcting the SqlContentEntityStorage.php and having the setting from admin/commerce/config/orders/settings to "Prevent the save and throw an exception that may cause a fatal error.." The following error is still occuring.
The difference now is that only 1 order will show these codes instead of all orders in the cart.

Type commerce_order

Message Drupal\commerce_order\Exception\OrderVersionMismatchException: Attempted to save order 4016 with version 43. Current version is 44. in Drupal\commerce_order\Entity\Order->preSave() (line 681 of public_html/modules/contrib/commerce/modules/order/src/Entity/Order.php).

Severity Error

And

Type php

Message Drupal\Core\Entity\EntityStorageException: Attempted to save order 4016 with version 43. Current version is 44. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of public_html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Severity Error

Code on line 681 of Order.php
public function preSave(EntityStorageInterface $storage) {
parent::preSave($storage);

if (isset($this->original) && !$this->isNew() && $this->original->getVersion() > $this->getVersion()) {
$mismatch_exception = new OrderVersionMismatchException(sprintf('Attempted to save order %s with version %s. Current version is %s.', $this->id(), $this->getVersion(), $this->original->getVersion()));
$log_only = $this->getEntityType()->get('log_version_mismatch');
if ($log_only) {
watchdog_exception('commerce_order', $mismatch_exception);
}
else {
throw $mismatch_exception;
}
}
$this->setVersion($this->getVersion() + 1);

Code on line 817 of SqlContentEntityStorage.php

public function save(EntityInterface $entity) {
try {
$transaction = $this->database->startTransaction();
$return = parent::save($entity);

// Ignore replica server temporarily.
\Drupal::service('database.replica_kill_switch')->trigger();
return $return;
}
catch (\Exception $e) {
if (isset($transaction)) {
$transaction->rollBack();
}
Error::logException(\Drupal::logger($this->entityTypeId), $e);
throw new EntityStorageException($e->getMessage(), $e->getCode(), $e);
}
}

@99gs3: Apply the patch from #3404282: Improve the order version exception logging and switch back to logging the exception... You should now have access to the strack trace which should hopefully help.
Also, this issue is outdated / closed, so let's stop updating it please :).

I've created a new issue to track this issue so we can stop updating this :D https://www.drupal.org/project/commerce/issues/3404382

Saw this in the log, dropping the stack trace here:
I presume this has something to do with a user reloading a cart, maybe with a different device, which causes a refresh, and saves the order, but not sure.

Drupal\commerce_order\Exception\OrderVersionMismatchException: Attempted to save order 20231 with version 6. Current version is 7. in /code/web/modules/contrib/commerce/modules/order/src/Entity/Order.php:719
Stack trace:
#0 /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(528): Drupal\commerce_order\Entity\Order->preSave(Object(Drupal\commerce_order\OrderStorage))
#1 /code/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(753): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\commerce_order\Entity\Order))
#2 /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(483): Drupal\Core\Entity\ContentEntityStorageBase->doPreSave(Object(Drupal\commerce_order\Entity\Order))
#3 /code/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(806): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\commerce_order\Entity\Order))
#4 /code/web/modules/contrib/commerce/modules/order/src/OrderStorage.php(169): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\commerce_order\Entity\Order))
#5 /code/web/core/lib/Drupal/Core/Entity/EntityBase.php(354): Drupal\commerce_order\OrderStorage->save(Object(Drupal\commerce_order\Entity\Order))
#6 /code/web/modules/contrib/commerce/modules/checkout/src/Plugin/Commerce/CheckoutFlow/CheckoutFlowBase.php(463): Drupal\Core\Entity\EntityBase->save()
#7 /code/web/modules/contrib/commerce/modules/checkout/src/Plugin/Commerce/CheckoutFlow/CheckoutFlowWithPanesBase.php(614): Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowBase->submitForm(Array, Object(Drupal\Core\Form\FormState))
#8 [internal function]: Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowWithPanesBase->submitForm(Array, Object(Drupal\Core\Form\FormState))
#9 /code/web/core/lib/Drupal/Core/Form/FormSubmitter.php(129): call_user_func_array(Array, Array)
#10 /code/web/core/lib/Drupal/Core/Form/FormSubmitter.php(67): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object(Drupal\Core\Form\FormState))
#11 /code/web/core/lib/Drupal/Core/Form/FormBuilder.php(597): Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object(Drupal\Core\Form\FormState))
#12 /code/web/core/lib/Drupal/Core/Form/FormBuilder.php(326): Drupal\Core\Form\FormBuilder->processForm('commerce_checko...', Array, Object(Drupal\Core\Form\FormState))
#13 /code/web/core/lib/Drupal/Core/Form/FormBuilder.php(224): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\MultistepDefault), Object(Drupal\Core\Form\FormState))
#14 /code/web/modules/contrib/commerce/modules/checkout/src/Controller/CheckoutController.php(143): Drupal\Core\Form\FormBuilder->getForm(Object(Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\MultistepDefault), 'login')
#15 [internal function]: Drupal\commerce_checkout\Controller\CheckoutController->formPage(Object(Drupal\Core\Routing\RouteMatch))
#16 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#17 /code/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#18 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#19 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#20 /code/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /code/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /code/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /code/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /code/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /code/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(116): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(90): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /code/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /code/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /code/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /code/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /code/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /code/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /code/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#35 {main}