In-memory order updater

[benjaminwil]

Summary

This pull request proposes a replacement to the default Spree::OrderUpdater that has new and improved functionality:

• Increased performance due to the updater making fewer write calls to the database.
• A built-in update simulator, so that changes to an order can be previewed before persisting them.

There may be some beneficial side-effects that come out of this new order updater implementation:

• Significantly faster order factories, and thus a significantly faster test suite for Solidus gems and Solidus applications.

We don't expect this to be the default order updater implementation in the next minor version of Solidus, but we would like to propose it as the default for the next major version of Solidus.

Note: The commits on this pull request have a long list of co-authors, as the Super Good team is approaching this as a collaborative mob programming exercise.

Milestones

For this order updater, we intend to achieve the following during updates:

1. Don't perform writes to the database.
2. Preload associated records to eliminate reads required.

We appreciate that there is a lot of complexity to achieving these goals (dealing with active promotions, for example).

Notes

• We should provide more context about performance gains in this PR description. It would be insightful to include the actual number of writes the current Spree::OrderUpdater makes on a typical recalculate.
• We should further explain why a production store may want to use an order update simulator so it's clear why this feature is worth having. For now, I'll just say that we have worked with stores who could benefit from this feature. Sometimes admins must make significant changes to completed orders, and it would be valuable for them to preview a set of changes before submitting them and causing updates on many order-associated tables.

Todo

• Add additional cases to item_total_updater_spec (doesn't currently account for included adjustments)
• Consider Sofia's recommendation to break this class into POROs to simplify testing
• Add test coverage for recalculate_item_total when line item totals change
• Scope handling of tax adjustments in InMemoryOrderUpdater to not marked for destruction
• Scope handling of tax adjustments in OrderUpdater to not marked for destruction
• Ensure order-level tax adjustments (like Colorado delivery) are scoped out of tax total and adjustment total calculations
• Handle persistence in update_taxes
• Write the InMemoryOrderAdjuster (also, should we rename this to InMemoryOrderPromotionAdjuster)
• Fix CI failures from previous session (if any)
• Add high-level integration test for legacy promotion system
• Verify if it is a breaking change to call (Mar 28, 2025)
  LineItem#set_required_attributes in after_initialize instead of
  before_validation. We think this may be a breaking change that requires
  further investigation. (We investigated and don't believe it is a breaking change.)
• Add high level test for manipulative queries around new Promotion system
  • (Optional) Add shared examples that could be used in both promotion system gems to
    ensure the above
• (In Progress) Handle persistence in all implementations of promotions.order_adjuster_class
  • Follow up on any failing test relating to change in promotion chooser
  • Ensure adjustments are marked for destructions instead of destroyed
  • Continue on with new promotion system similar change
    • DiscountOrder
• Investigate if any promotion actions/benefits write to the database when calling compute_amount. We know the create quantity adjustments does. This action persists when compute_amount is called.
  • Promotion Actions (Legacy Promotion System)
  • Benefits (New Promotion System)
• (In Progress) Add the ability to raise an error (or log it) if something tries to persist data during a call to the in-memory order updater with persist: false
  • Implementation reference
  • ActiveSupport::Notifications
  • "By calling this in memory order updater, we are making a contract with the user that it won't persist"
  • "This is really something which theoretically should be covered in tests"

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[jarednorman]

Just making a note that we are waiting on Alistair to rebase #6026 against this.

@AlistairNorman could you just make sure that gets done at some point before the 20th? That way we can have it for our next session.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.76%. Comparing base (ca1ae4d) to head (92fc679).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5872      +/-   ##
==========================================
- Coverage   92.42%   88.76%   -3.67%     
==========================================
  Files         389      831     +442     
  Lines        8005    18102   +10097     
==========================================
+ Hits         7399    16069    +8670     
- Misses        606     2033    +1427     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jarednorman]

Next steps:

1. One group can continue with the next two items on the todo list (finishing adding high-level tests for the new promotion system and handling any persistence call that fall out of that work).
2. The other group can start working on adding the ability to raise errors or log events when persistence happens inside of order updates.