Rails 4.1 added time helpers but we never bothered using them. But now
I'm getting rid of the Timecop dependency and use standard helpers.
Beware though that the new helpers always freeze time. When you travel
to a certain date then the clock stops ticking while Timecop maintained
the passing of time.
The freezing of time could cause problems if you are trying to enforce a
timeout. But all current specs don't seem affected.
In most cases, the freezing will make it easier to avoid flaky specs.
The main point of the test is to alert us if the query count increased (https://github.com/openfoodfoundation/openfoodnetwork/pull/13232#discussion_r2199896280).
The missing query in rails 7.1:
Spree::StockItem Load SELECT "spree_stock_items"."id", "spree_stock_items"."variant_id", "spree_stock_items"."count_on_hand", "spree_stock_items"."created_at", "spree_stock_items"."updated_at", "spree_stock_items"."backorderable", "spree_stock_items"."deleted_at", "spree_stock_items"."lock_version" FROM "spree_stock_items" WHERE "spree_stock_items"."id" = $1 LIMIT $2 FOR UPDATE
This name better reflects what it's doing.
As this job is scheduled automatically by Sidekiq, I think there shouldn't be any jobs with the old name in redis. So I didn't bother keeping a placholder for the old name.
And Clean up unused include
After 10 minutes, I'd consider that it failed to open the order cycle. Who would want their products to sync, or get a notification at a random time during the order cycle?
Best viewed with whitespace ignored.
Being based on the DB value should be more robust.
This prevents an order cycle from being "opened" when it's already open. But note that the order cycle can become "unopened" (see OrderCycle#reset_opened_at).
Nice to see the database query count drop, but I must confess I don't know why!
There might be a delay before it gets sent, so it's better to record the time the event occurred at.
It would have been simpler to just add it to the data hash, but I felt it was an important detail for an event and should be at the top level along with event name.
In the case of order cycle opening, this is the same as opened_at. I've included this in the payload for clarity too.
Update every single order line to reflect local orders and stock levels.
New cases supported:
* Add lines for orders created by an admin.
* Create backorder line after increase of local line item quantity.
* Adjust local stock after variant has been removed from order cycle.
The new job class blends code from the BackorderJob and the
CompleteBackorderJob for the specific case of adjusting quantities after
an order has been cancelled.
I would like to write a more general class which can be used for any
order amendmends but this was the quickest solution to cater for
currently running pilots.
This will delay the checkout request by a few seconds if there's stock
to sync. But we minimise the chance of missing reduced stock from orders
on another platform.
We still have a gap between the checkout and placing a backorder. In
that time we can't guarantee enough stock. But let's tackle that after
the pilot.
We want to trigger the backordering for any linked product now. So let's
do that check early and then select the variants in the background.
It means less data passed to the job and less space for race conditions.
From Sidekiq's view, the job is successful when we rescue an error and
it will discard it. But we want the option to inspect the job and retry
it. Failing jobs are also reported to Bugsnag automatically.
I didn't specify `retry: false` because that discards the job as well.
But `retry: 0` should sent it straight to the dead set. No automatic
retries but it's treated like a failed job.
