"Recalculate shipping" button will update an order even after order is complete

it is in fact PayPal WPP, and unfortunately these incidents go unnoticed for a few days at a time. The logs get overloaded and dumped with other events by the time I can review them (it's a pretty high traffic website)

Do you think it could be the checkout pane config?

could you quickly answer these 2 questions, or point me to some docs on these:

which pane submission leads to the creation of a new account?

where is the code that assigns pane ownership and order ownership to the newly created account?

This issue came back up and is continuing to cause problems.

I did some digging and found an interesting problem in the commerce_order_revisions table.

It seems that the order process worked just fine, but somehow, the timestamp of one of the revisions is off by 1 hour.

The result is that subsequent "commerce_order_load" calls will load an outdated revision of the order.

The initial payment processing works, because the order is in tact and the proper amount is charged.

When the order is then loaded at later dates, an outdated revision is loaded and the shipping and billing relationships are no longer correct.

Here's a sample of the table data:

revision_id    status              revision_timestamp          
22732          cart                1379814027 (09 / 21 / 13 @ 8:40:27pm EST)
22733          checkout_checkout   1379818021 (09 / 21 / 13 @ 9:47:01pm EST)
22734          checkout_review     1379814500 (09 / 21 / 13 @ 8:48:20pm EST)
22735          checkout_payment    1379814500 (09 / 21 / 13 @ 8:48:20pm EST)
22736          checkout_complete   1379814509 (09 / 21 / 13 @ 8:48:29pm EST)
22737          completed           1379814509 (09 / 21 / 13 @ 8:48:29pm EST)

The payment, complete and completed status updates occurred after the checkout update. You can see this because the revision id's have incremented between checkout and completed.

However, for some reason the "checkout_checkout" status timestamp is 1 hour ahead of all the subsequent updates. As a result, when the order is loaded from the database, and not from the cache, the wrong revision is loaded.

The default timezone on the server is Arizona time, which doesn't recognize Daylight Savings.. I wonder if that's not messing with this somehow. As far as I can tell the timestamp here is controlled by the REQUEST_TIME constant...

Do you know of any way that REQUEST_TIME is getting bumped an hour ahead on the checkout_checkout page?

crap it's not always an hour off.. sometimes just a few minutes. I was hoping I was onto something with timezone but no.. these 2 orders have the same issue and are only a few minutes ahead with the "checkout_checkout" status revision:

revision_id    status              revision_timestamp          
12724          cart                1369858710 (05 / 29 / 13 @ 3:18:30pm EST)
12728          checkout_checkout   1369860274 (05 / 29 / 13 @ 3:44:34pm EST)
12734          checkout_review     1369860212 (05 / 29 / 13 @ 3:43:32pm EST)
12735          checkout_payment    1369860212 (05 / 29 / 13 @ 3:43:32pm EST)
12736          checkout_complete   1369860228 (05 / 29 / 13 @ 3:43:48pm EST)
12737          completed           1369860228 (05 / 29 / 13 @ 3:43:48pm EST)


revision_id    status              revision_timestamp          
9249           cart                1365894228 (04 / 13 / 13 @ 6:03:48pm EST)
9251           checkout_checkout   1365894529 (04 / 13 / 13 @ 6:08:49pm EST)
9252           checkout_review     1365894462 (04 / 13 / 13 @ 6:07:42pm EST)
9253           checkout_payment    1365894462 (04 / 13 / 13 @ 6:07:42pm EST)
9254           checkout_complete   1365894466 (04 / 13 / 13 @ 6:07:46pm EST)
9255           completed           1365894466 (04 / 13 / 13 @ 6:07:46pm EST)

I think I'm not the only one having this problem:
#2052755: Prevent orders from reversion to out-of-date revision, which causes loss of data after payment is made.

That sounds very similar.. Orders are mysteriously reverting back to out-of-date revisions.

Unfortunately this is extremely difficult to troubleshoot. It only happens on about 1% of the orders that come through the site. It unfortunately disrupts the order fulfillment process which is a gigantic problem since people are making payments, but the system is not firing rules properly...

Is it possible that the user completes checkout, and the goes back to a certain pane with the back button? Would that cause this issue to occur?

closing as duplicate of #2052755: Prevent orders from reversion to out-of-date revision, which causes loss of data after payment is made.

OK I figured it out.

To reproduce:
Configuration: Put shipping on the "checkout" page, Put payment on a subsequent checkout page

1) Add items to cart
2) Checkout
3) Open a new tab (in my case, I have a link to shipping policy with target="_blank" on the shipping pane)
4) Go back to checkout in the new tab, leaving the original tab open on the shipping entry page.
5) Complete checkout in the new tab.

Your order is complete, and a payment is made, you can't navigate back to the "checkout" page that has the shipping pane, but if you opened a new tab in step 3, then your old tab is still open with that page.

6) Now click "Recalculate shipping" on the old tab that still shows the checkout page

The order state will revert to "Checkout" and the revision number rolls back to the revision that was active when the "Checkout" page was originally loaded.

This is an unlikely series of events, but it has happened to me about 5 times now. Removing my link with the target="_blank" attribute would probably further decrease the likelihood of these events, but the fact that people are clicking it says to me it serves a purpose, and users are likely to want to navigate the site to review policies in a new tab. Even without that link, it's possible that users will still open a new tab and end up doing the same thing.

The really tricky thing about this is that the user doesn't even have to click "Continue to next step"

Because the "Recalculate shipping" is fired on several DOM events (like onChange of ZIP code) -- you could easily accidentally trigger the update without even clicking on any buttons.

I think a key part of this is the fact that the ajax submission handler for the pane, as defined in commerce_shipping_recalculate_services_submit(), uses the $form_state['order'] order object, which can be out of date if the order was manipulated elsewhere.

function commerce_shipping_recalculate_services_submit($form, &$form_state) {
  $order = $form_state['order'];
  // ...

By contrast, commerce_checkout_form_validate() will load "a fresh copy of the order stored in the form":

function commerce_checkout_form_validate($form, &$form_state) {
  global $user;

  $checkout_page = $form_state['checkout_page'];

  // Load a fresh copy of the order stored in the form.
  $order = commerce_order_load($form_state['order']->order_id);
  // ...

Shouldn't Commerce Shipping also use a "fresh copy" of the order?

no sorry i forgot to update the version after moving from Drupal Commerce to Commerce Shipping

patch attached. this prevents the recalculation from occurring when the user makes changes in a shipping pane on an expired checkout page