FIx a stale data issue when using Spree::OrderCapturing.

[Senjai]

As described in the comment, calling payment.capture! triggers an
after_save on Spree::Payment. In this after_save, things can happen, one
of those things is an order.update!.

That means if the order.update! happens within a payment after save, the order we have stored in @order is now out of date, and has to be reloaded.

If we don't reload it, the hooks in the order updater will be called
twice. If they make decisions around fresh state changes, idempotency
could be compromised. cc @athal7

[gmacdougall]

👍

[jhawthorn]

This needs a test.

[jordan-brough]

This shouldn't happen if inverse_of is set up correctly, right?

I thought that was automatic in our version of Rails but it doesn't seem to be happening for me. Maybe it's because of one of the options we put on our belongs_to or our has_many? Or maybe I'm imagining the automatic-ness.

When I test out the current state of the code:

>> o = Spree::Order.complete.last; o.object_id
=> 70196650722200
>> o.payments.pending.to_a.first.order.object_id
=> 70196674897280

We do have an inverse_of set up here on Payment: https://github.com/solidusio/solidus/blob/157365b/core/app/models/spree/payment.rb#L9
But not on Order: https://github.com/solidusio/solidus/blob/157365b/core/app/models/spree/order.rb#L52

If I change the Order relationship to: has_many :payments, dependent: :destroy, inverse_of: :order then I get:

>> o = Spree::Order.complete.last; o.object_id
=> 70151364663080
>> o.payments.pending.to_a.first.order.object_id
=> 70151364663080

Can we add a test and then see if correcting the inverse_of relationship will fix this without a reload?

[jhawthorn]

I agree with @jordan-brough, but that needs to be tested thoroughly. We don't want to re-introduce this spree 2.2 era regression.

https://github.com/solidusio/solidus/blob/v1.1.0/core/spec/models/spree/order/payment_spec.rb#L70-L74

Either way, we should get a test first 😉

[jordan-brough]

@jhawthorn wow, great memory! If adding inverse_of becomes a huge effort then I'm 👍 on this PR as-is and then opening an issue around figuring out how to add inverse_of separately.

[jhawthorn]

👍

I'm really interested in seeing inverse_of added, but that shouldn't hold up this PR.

[jordan-brough]

Note: inverse_of investigation PR here: #414