Avoid unnecessary adjustment persistence in tax calculations#6315
Merged
tvdeyen merged 2 commits intosolidusio:mainfrom Sep 9, 2025
Conversation
github-actions
bot
added
the
changelog:solidus_core
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6315 +/- ##
=======================================
Coverage 89.35% 89.35%
=======================================
Files 961 961
Lines 20180 20181 +1
=======================================
+ Hits 18031 18032 +1
Misses 2149 2149 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
benjaminwil
force-pushed
the
avoid-unnecessary-adjustment-persistence-in-tax-calculations
branch
from
a389114 to
805c295
Compare
jarednorman
approved these changes
Aug 26, 2025
To support the in-memory order updater, we want adjustments to be modified without writing to the database immediately. We added `autosave: true` in the association on line_items ensures that the adjustment amount will be saved with the line_item, or by extension the order when it is eventually persisted by the order updater. The tests for the OrderTaxation have been updated to use `size` instead of `count` to ensure an in-memory reported count/size. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Andrew Stewart <andrew@super.gd> Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Noah Silvera <noah@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd>
Instead of actually destroying adjustments in the OrderTaxation class, we can just mark them for removal. This will allow them to be removed when the order is persisted, instead of being removed during the recalculate process. This is an improvement in service of recalculating order changes without writing to the database. We also need to ensure `Order#adjustments` association has autosave enabled so that the marked for destruction adjustments are removed when we persist the order. We're also improving our OrderUpdater tests to better verify our changes maintain the existing behaviour. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Harmony Bouvier <harmony@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd> Co-authored-by: Senem Soy <senem@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
tvdeyen
force-pushed
the
avoid-unnecessary-adjustment-persistence-in-tax-calculations
branch
from
805c295 to
c2cd061
Compare
tvdeyen
approved these changes
Sep 5, 2025
Member
tvdeyen
left a comment
tvdeyen
left a comment
There was a problem hiding this comment.
Amazing! TIL mark_for_destruction
| has_one :product, through: :variant | ||
|
|
||
| has_many :adjustments, as: :adjustable, inverse_of: :adjustable, dependent: :destroy | ||
| has_many :adjustments, as: :adjustable, inverse_of: :adjustable, dependent: :destroy, autosave: true |
Contributor
There was a problem hiding this comment.
@benjaminwil @jarednorman we missed autosaving the shipment adjustments in this PR, and it's resulting in shipment tax adjustments not getting persisted correctly in Solidus 4.6.0 .... draft PR incoming to address it!
Noah-Silvera
added a commit
to SuperGoodSoft/solidus
that referenced
this pull request
Oct 17, 2025
A commit was made in solidusio#6315 (5979f25) in service of the in memory order updater solidusio#5872 that changed the behavior in the OrderTaxation class to set the adjustment value but not persist it. Instead, the persistence happens when the order is saved. If a shipment is changed, and an associated adjustment is changed, the shipment adjustment will be autosaved when the order is. However, if a shipment is *not* changed, but the adjustment is, the adjustment will *not* be autosaved when the order is. A scenario where this can happen is a recalculation that just adjusts shipment taxes on an order that would otherwise not change. Let's walk through what happens in the OrderUpdater 1. `update_totals` is called which in turn... 2. calls `update_adjustment_total`, which in turn... 3. calls `recalculate_adjustments` which in turn... 4. Calls `update_tax_adjustments` - `update_tax_adjustments` creates and sets the values of the tax adjustments for a shipment. At this point, the shipment adjustment has been changed, but not persisted, and the shipment has *not* been changed. 5. Calls `update_item_totals` which calls... 6. `Spree::Config.item_total_class.new(item).recalculate!` - `Spree::Config.item_total_class` sets the `included_tax_total`, `additional_tax_total` and `adjustment_total` on the shipment to their new values, calculated from the non-persisted adjustment. At this point, both the shipment *and* adjustment have been changed but not persisted. - If you were to call `order.save!` at this point, the shipment adjustment would autosave. 7. Next, `item.update_columns` is called with the columns that the `item_total_class` updated. - At this point, the shipment, it's changes having been persisted to the database, will no longer be marked as `changed`. - This means that the default behavior of autosave in rails will *not* save the shipment when the order is saved, which means the associated (and changed) adjustment will not get saved either In solidusio#6315, we ensured that these changed associations cannot get left behind by setting `autosave: true`, which forces the model to check if it has any associations that need saving instead of telling it's relation "nope I haven't changed" We can do the same thing here for the shipment to ensure changing adjustments will make the shipment tell it's order "I have changed", even if none of it's direct properties have changed. You can test this change by removing the `autosave: true` option the adjustments and running 'when the address has changed to a different state' specs. They fail with the error "expected `order.shipments.first.adjustments.first.amount` to have changed from 1 to 2, but did not change", demonstrating a scenario where the shipment adjustment changes do not get persisted.
Noah-Silvera
added a commit
to SuperGoodSoft/solidus
that referenced
this pull request
Oct 17, 2025
A commit was made in solidusio#6315 (5979f25) in service of the in memory order updater solidusio#5872 that changed the behavior in the OrderTaxation class to set the adjustment value but not persist it. Instead, the persistence happens when the order is saved. If a shipment is changed, and an associated adjustment is changed, the shipment adjustment will be autosaved when the order is. However, if a shipment is *not* changed, but the adjustment is, the adjustment will *not* be autosaved when the order is. In solidusio#6315, we ensured that these changed associations cannot get left behind by setting `autosave: true`, which forces the model to check if it has any associations that need saving instead of telling it's relation "nope I haven't changed" We can do the same thing here for the shipment to ensure changing adjustments will make the shipment tell it's order "I have changed", even if none of it's direct properties have changed. You can test this change by removing the `autosave: true` option the adjustments and running 'when the address has changed to a different state' specs. They fail with the error "expected `order.shipments.first.adjustments.first.amount` to have changed from 1 to 2, but did not change", demonstrating a scenario where the shipment adjustment changes do not get persisted.
5 tasks
Noah-Silvera
added a commit
to SuperGoodSoft/solidus
that referenced
this pull request
Oct 17, 2025
A commit was made in solidusio#6315 (5979f25) in service of the in memory order updater solidusio#5872 that changed the behavior in the OrderTaxation class to set the adjustment value but not persist it. Instead, the persistence happens when the order is saved. If a shipment is changed, and an associated adjustment is changed, the shipment adjustment will be autosaved when the order is. However, if a shipment is *not* changed, but the adjustment is, the adjustment will *not* be autosaved when the order is. In solidusio#6315, we ensured that these changed associations cannot get left behind by setting `autosave: true`, which forces the model to check if it has any associations that need saving instead of telling it's relation "nope I haven't changed" We can do the same thing here for the shipment to ensure changing adjustments will make the shipment tell it's order "I have changed", even if none of it's direct properties have changed. You can test this change by removing the `autosave: true` option the adjustments and running 'when the address has changed to a different state' specs. They fail with the error "expected `order.shipments.first.adjustments.first.amount` to have changed from 1 to 2, but did not change", demonstrating a scenario where the shipment adjustment changes do not get persisted.
Noah-Silvera
added a commit
to SuperGoodSoft/solidus
that referenced
this pull request
Oct 17, 2025
A commit was made in solidusio#6315 (5979f25) in service of the in memory order updater solidusio#5872 that changed the behavior in the OrderTaxation class to set the adjustment value but not persist it. Instead, the persistence happens when the order is saved. If a shipment is changed, and an associated adjustment is changed, the shipment adjustment will be autosaved when the order is. However, if a shipment is *not* changed, but the adjustment is, the adjustment will *not* be autosaved when the order is. In solidusio#6315, we ensured that these changed associations cannot get left behind by setting `autosave: true`, which forces the model to check if it has any associations that need saving instead of telling it's relation "nope I haven't changed" We can do the same thing here for the shipment to ensure changing adjustments will make the shipment tell it's order "I have changed", even if none of it's direct properties have changed. You can test this change by removing the `autosave: true` option the adjustments and running 'when the address has changed to a different state' specs. They fail with the error "expected `order.shipments.first.adjustments.first.amount` to have changed from 1 to 2, but did not change", demonstrating a scenario where the shipment adjustment changes do not get persisted.
github-actions bot
pushed a commit
that referenced
this pull request
Oct 21, 2025
A commit was made in #6315 (5979f25) in service of the in memory order updater #5872 that changed the behavior in the OrderTaxation class to set the adjustment value but not persist it. Instead, the persistence happens when the order is saved. If a shipment is changed, and an associated adjustment is changed, the shipment adjustment will be autosaved when the order is. However, if a shipment is *not* changed, but the adjustment is, the adjustment will *not* be autosaved when the order is. In #6315, we ensured that these changed associations cannot get left behind by setting `autosave: true`, which forces the model to check if it has any associations that need saving instead of telling it's relation "nope I haven't changed" We can do the same thing here for the shipment to ensure changing adjustments will make the shipment tell it's order "I have changed", even if none of it's direct properties have changed. You can test this change by removing the `autosave: true` option the adjustments and running 'when the address has changed to a different state' specs. They fail with the error "expected `order.shipments.first.adjustments.first.amount` to have changed from 1 to 2, but did not change", demonstrating a scenario where the shipment adjustment changes do not get persisted. (cherry picked from commit b47e0f0)
tvdeyen
pushed a commit
that referenced
this pull request
Oct 21, 2025
A commit was made in #6315 (5979f25) in service of the in memory order updater #5872 that changed the behavior in the OrderTaxation class to set the adjustment value but not persist it. Instead, the persistence happens when the order is saved. If a shipment is changed, and an associated adjustment is changed, the shipment adjustment will be autosaved when the order is. However, if a shipment is *not* changed, but the adjustment is, the adjustment will *not* be autosaved when the order is. In #6315, we ensured that these changed associations cannot get left behind by setting `autosave: true`, which forces the model to check if it has any associations that need saving instead of telling it's relation "nope I haven't changed" We can do the same thing here for the shipment to ensure changing adjustments will make the shipment tell it's order "I have changed", even if none of it's direct properties have changed. You can test this change by removing the `autosave: true` option the adjustments and running 'when the address has changed to a different state' specs. They fail with the error "expected `order.shipments.first.adjustments.first.amount` to have changed from 1 to 2, but did not change", demonstrating a scenario where the shipment adjustment changes do not get persisted. (cherry picked from commit b47e0f0)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
These commits were originally part of the work on the in-memory order updater (#5872).
Rather than updating or deleting adjustment records on recalculate, we can assign new attributes or mark the records for destruction and reduce the total distinct writes necessary to recalculate an order during updates.
Checklist