Bugsnag expects a string as value, not an ActiveRecord object. The
result was just "filtered" data, not showing any of the order's
attributes.
Since wanting to share the order data seems a common pattern, I added a
convenience method for it.
This reverts commit 2eec3d625a.
We started tracking 404 errors out of interest without an actual problem
to solve. Now we face rate-limiting in our Bugsnag account. And we
didn't use these 404 reports in the two years this code was active. We
don't even act on all 500 errors. So while our resources are so
constrained, let's keep our focus on the severe errors and user reports
and ignore the rest. 404 errors are mostly generated by vulnerability
scanners.
I disabled Metrics/AbcSize for ensure_standard_variant as I don't think
that's hard to understand the code. And utimately it will be removed
once product actually becomes optional.
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.
The method `CheckoutCallbacks#valid_order_line_items?` was a duplicate
of `OrderStockCheck#valid_order_line_items?`.
Apparently, it had been extracted twice:
* 1d074c2151
* 06eb98bdf4
But the first commit duplicated the method while the second moved the
original declaration.
The VINE Api require a secret and an API key to be used. The secret is
used to sign the request. The secret is linked to the API key so we need
to store it along side the key.
This also resolves a race condition scenario. Even if the report gets
rendered via websockets before the controller response is rendered then
the fallback script loads the report again. It's not the most beautiful
but probably okay until we replace websockts altogether.
I'm leaving websockets in at the moment because it can render the report
much quicker than polling can.
I'm adding TurboPower for the scroll_into_view action. It adds all the
nice CableReady actions to Turbo Streams.
Note that I omitted `block: "start"` because that option is the default
in Javascript. And the generic `action` method doesn't support
parameters like this anyway. I'll work on that in the next commit.
I also re-introduced a race condition by rendering the "loading"
indicator after triggering the report rendering job. I'm planning to
resolve that later.
