Error: Call to a member function getState()

I installed updates on the site that had this errors. Since then, the error doesn't occur anymore. Might this be outdated? @tcrawford could you check if your issue is solved as well by installing updates?

@Lukas von Blarer: Which modules did you update? Shipping? Commerce? Everything?

@jsacksick I updated everything. Here is a list of the relevant updates:

PHP 7.4 to 8.1
drupal/core 9.4.8 to 9.5.3
drupal/commerce 2.31.0 to 2.33.0
drupal/commerce_shipping 2.4.0 to 2.5.0

Feel free to ask more specific questions, in case you need more info. You can also ping me on Slack.

@Lukas I will update of commerce_shipping (and likely core as it needs to be done soon) and see if that resolves the issue.

For the project with the issue we are on
PHP 8.0
drupal/core 9.4.11
drupal/comerce 2.33, and
drupal/commerce_shipping 2.4.

nielsva → made their first commit to this issue’s fork.

We're also seeing this bug and can pretty neatly reproduce the problem. We've also got commerce_shipment enabled which automatically generates the correct shipment methods. Some things that catch my eye are:

1. The order should not yet have existed before landing on `checkout/12345/order_information`, only then this error triggers on our "Continue to review" button and does so in a AJAX request in the background.
2. If you add shipment address info and the shipment methods are attempted to be displayed, it will not show the shipment methods.
3. If you've done that, refreshing the page will strangely show all shipment methods.
4. At this point, you can click on "Continue to review" without triggering the error.

This issue has arrived in our project when upgrading Drupal core and a lot of contrib modules, but notably we also update commerce contribs:

drupal/commerce                    | 2.30.0       | 2.33.0    
drupal/commerce_cart               | 2.30.0       | 2.33.0    
drupal/commerce_checkout           | 2.30.0       | 2.33.0   
drupal/commerce_mollie             | 1.7.0        | 1.10.0    
drupal/commerce_number_pattern     | 2.28.0       | 2.33.0   
drupal/commerce_order              | 2.28.0       | 2.33.0    
drupal/commerce_payment            | 2.28.0       | 2.33.0   
drupal/commerce_price              | 2.30.0       | 2.33.0    
drupal/commerce_pricelist          | 2.4.0        | 2.8.0   
drupal/commerce_product            | 2.30.0       | 2.33.0   
drupal/commerce_shipping           | 2.2.0        | 2.6.0   
drupal/commerce_store              | 2.30.0       | 2.33.0    
drupal/commerce_store_domain       | 1.0.0-rc2    | 1.0.0

I've done a suggestion on how to fix this, but I'm not entirely sure if this is the right way. Though, I would think this is a safe way to solve this issue where it will self recover from a serialized state and reinitialise it's Order object.

Feedback wanted.

Patch for reference what we are currently applying to our project and not patching from the actual MR.

I stumbled upon this for the first time today... I'm just annoyed that we can no longer rely on $this->order once we commit this... I'll need to give this a closer look tomorrow.

I'm wondering if we shouldn't simply revert https://git.drupalcode.org/project/commerce/-/commit/8768730e21fc2fff88c...... I mean, this would be a breaking change, but I'd prefer that over the approach from patch #16.

Changed my mind and decided to go ahead and commit the patch from #16, thanks @nielsva for thorough analysis and patch!

Automatically closed - issue fixed for 2 weeks with no activity.