Leaving the object with unpersisted changes breaks order locking with this error (in various places):
RuntimeError:
Locking a record with unpersisted changes is not supported. Use `save` to persist the changes, or `reload` to discard them explicitly.
Rails 5.2 has changed the way initializers are called during certain rake tasks including `db:create`. Initializers that were previously not loaded are now loaded (basically the whole app is loaded). This means any calls to #table_exists? that appear in the app will throw fatal errors as the database doesn't exist yet during that task, but those calls are made before `db:create` has even started, which means the database can't be created.
There are also a few other places in Spree code where #table_exists? is called, and they already call #connected? first to guard against this issue.
Enumerable#uniq is fine (eg calling #uniq on an Array object), but now using #uniq on an ActiveRecord::Relation is deprecated in favour of #distinct (which modifies the query itself, as opposed to iterating over the results of the query).
DEPRECATION WARNING: ActiveModel::Errors#set is deprecated and will be removed in Rails 5.1. Use model.errors.add(:preferred_discount_amount, ["has an invalid format. Please enter a number."]) instead. (called from block (2 levels) in localize_number at /home/runner/work/openfoodnetwork/openfoodnetwork/lib/spree/localized_number.rb:38)
This class is currently used and it gets skipped when the
:customer_balance toggle is enabled, so there's no point on abstracting
the balance with `OrderBalance`. It'll never go through its
`#new_outstanding_balance` branch and it'll be removed once we active
that toggle to everyone.
This will let us branch by abstraction. All existing calls to
`#outstanding_balance` will go through `OrderBalance` hence, will
check the feature toggle.
Note that by default, `OrderBalance` will end up calling
`#old_outstanding_balance`. As the name states, that's exactly what
`#outstanding_balance` was so far. This means no consumers will see any
change in behavior. We just added on item in the call stack (sort of).
We observed invalid payment states in Bugsnag but we don't actually know
in which state the payment intent was in. From the context we can guess
that it was "succeeded" but it would be good to validate this. And in
the future it would be good to know if there are other invalid states we
can end up in.
The notification to Bugsnag happens in another part of the code.
