This guard clause was returning an instance of an unpermitted Params object (containing a blank hash) here, which was causing unexpected results in various places. Returning a blank hash explicitly resolved the issue.
Fixes:
4) Admin::OrderCyclesController create as a manager of a shop when creation is successful returns success: true and a valid edit path
Failure/Error:
@order_cycle_params ||= PermittedAttributes::OrderCycle.new(params).call.
to_h.with_indifferent_access
ActionController::UnfilteredParameters:
unable to convert unpermitted parameters to hash
# ./app/controllers/admin/order_cycles_controller.rb:245:in `order_cycle_params'
# ./app/controllers/admin/order_cycles_controller.rb:44:in `create'
# ./spec/support/controller_requests_helper.rb:49:in `process_action_with_route'
# ./spec/support/controller_requests_helper.rb:27:in `spree_post'
# ./spec/controllers/admin/order_cycles_controller_spec.rb:124:in `block (5 levels) in <module:Admin>'
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.
Fixes:
2) Spree::Classification won't destroy if classification is the primary taxon
(Used from /home/runner/work/openfoodnetwork/openfoodnetwork/spec/models/enterprise_group_spec.rb:43:in `block (3 levels) in <top (required)>')
Failure/Error: expect(classification.destroy).to be false
Fixes:
Api::V0::TaxonsController as an admin cannot create a new taxon with invalid taxonomy_id
Failure/Error: expect(json_response["error"]).to eq("Invalid resource. Please fix errors and try again.")
expected: "Invalid resource. Please fix errors and try again."
got: nil
(compared using ==)
# ./spec/controllers/api/v0/taxons_controller_spec.rb:105:in `block (3 levels) in <top (required)>'
Fixes:
Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /home/runner/work/openfoodnetwork/openfoodnetwork/spec/models/spree/payment_spec.rb:10:in `block (3 levels) in <top (required)>'.
RuntimeError:
stubbed models are not allowed to access the database - Spree::Product#touch(updated_at,{:time=>2021-04-10 14:24:50 UTC})
The test setup left the object with unsaved changes, which doesn't work nicely with the new order locking added recently on the edit action.
Fixes ~5 specs including:
5) CheckoutController redirection to cart and stripe redirects when some items are out of stock
Failure/Error:
order.with_lock do
lock_variants_of(order)
yield
end
RuntimeError:
Locking a record with unpersisted changes is not supported. Use `save` to persist the changes, or `reload` to discard them explicitly.
# ./app/services/current_order_locker.rb:22:in `lock_order_and_variants'
# ./app/services/current_order_locker.rb:11:in `around'
# ./spec/controllers/checkout_controller_spec.rb:57:in `block (3 levels) in <top (required)>'
Fixes:
Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /home/runner/work/openfoodnetwork/openfoodnetwork/spec/models/spree/payment_spec.rb:10:in `block (3 levels) in <top (required)>'.
RuntimeError:
stubbed models are not allowed to access the database - Spree::Product#touch(updated_at,{:time=>2021-04-10 14:24:50 UTC})
A spec failed with this message:
ActiveRecord::ConnectionTimeoutError:
could not obtain a connection from the pool within 5.000 seconds (waited 5.000 seconds); all pooled connections were in use
The error seems to be raised when trying to authenticate the user
through Devise in a before_action block. Increasing the pool size by one
helped.
I don't know why our app needs more than 5 connections at the same time.
Maybe some gem "forgets" to release connections?
