Rails has changed the way helpers are loaded. It's a bit weird. It was throwing lots of errors, and recommended using this setting, but now requires that all helpers are loaded explicitly. I'm not sure about this.
The mismatched use of hash attributes as strings and hash attributes as symbols here (attrs['name'] and attrs[:name]) meant that the conditional was not returning the expected results in the test.
As a general rule, if you're triggering an email job as part of an after create/save callback, it should use after commit instead.
Why? The transaction can't finish until after the record is persisted (the data is committed) which includes the logic in all callbacks. So for example if the transaction fails after the email job has been placed it will be rolled back, but the email job will already be in the queue, and it'll be referencing a record that doesn't actually exist (due to the rollback).
This is a generic issue caused by a clash between state machines trying to define (or failing to define) the #open method on adjustments as part of their state changes interface. This method is already defined in Object. For more details, see: bb42e33bf7/lib/state_machines/machine.rb (L323-L350)
This used to happen via an after_save callback in Shipment, which called `order.update!`. That has recently been removed. After changing a shipment's selected shipping rate (shipping method), we need to ensure the order's totals and states are updated. We don't need to update all of the order's adjustments though (see previous commit).
FYI Spree handled this issue like this: 24388485ed, but there are lots of things about that commit that are clearly awful, like: params handling in a model, duplication of Order::Updater logic across the codebase, the Shipment class having responsiblity for knowing which things need to be updated on the order, etc. The result is ultimately the same as what we're doing here though.
There are two distinct (and very important) operations happening here. The first is to update all adjustments (which can be *incredibly* expensive) and the second is to ensure the order's totals and shipping/payment states are correct. There are lots of places where we currently do both of these things where in fact we only need to do the latter (and skip the really expensive part).
Error is
```
Failure/Error: @app.call(env)
LoadError:
Unable to autoload constant Api::V0::OrderCyclesController, expected /Users/jibees/dev/openfoodnetwork/app/controllers/api/v0/order_cycles_controller.rb to define it
```