| Age | Commit message (Collapse) | Author |
|---|
|
This way we can provide more flexibility on things that can be
done when an error occurs.
In the provided RailsLogger handler, we'll also print the ID
of the installment.
|
|
At the moment, by default, all installment prceissing errors are
swallowed and there's no way for a developer to understand what's
happening. Of course they can create a custom handler with the
processing_error_handler configuration provided but usually, when
the first errors happen, it's too late and those errors are lost.
We are not raising errors of this job because if there's a retry
mechanism in place for Active Job, the installment will be
reprocessed twice. Once by Active Job and once by the installment
retry mechanism already provided by the extension.
Logging to Rails.error is a middle-ground that allows to intercept
the message of the exception. Still, creating a custom handler
based on the bug tracker/exception handler used is the suggested
option here.
|
|
not_to raise_error should never be ued with specific error classes,
since any other error would make the test pass, including the ones
raised by Ruby, meaning that the code being tested may never be reached.
|
|
Update specs to conform with rubocop
|
|
|
|
This disables the ActiveJob default retry mechanism because installment
processing failures are already taken care of by solidus_subscriptions.
Before this, there was a potentional for double retrying, which could
causes background jobs and cancelled orders to accumulate leading
to side effects such as a bad customer experience.
Now, a `process_job_error_handler` configuration Proc is called when a
ProcessInstallmentJob `#perfom` method fails.
The rescued error can be managed/logged as preffered, or re-raised
if the default retry behaviour is required in the job.
|
|
|
|
This change moves the processing of individual subscriptions to their
own isolated jobs. The tasks of these individual jobs will be:
- Deactivate/Cancel subscriptions pending one of those operations
- Clear any past failed installment if it's configured to do so
- Create a new installment for the subscription cycle
- Enqueue a job to process any actionable installment for the
subscription
Given we've moved the concern of queueing the installment processing,
that part can be removed safely from the main processor job. The final
part of the change also touches the main processor job, whose task is
now to collect any actionable subscription and any subscription with
an actionable installment to enqueue them for individual processing.
|
|
Instead of attempting to process multiple installments at a time, which
increases the chances something might go wrong, we are now only processing
one installment at a time.
This also improves the extension's performance, because the installments
can be processed in parallel.
|
|
|
|
Consolidated installment is long and confusing. It also doesn't really
describe what the class is doing.
Really this is a Checkout class.
|
|
Consolidated installments make the assumption that all installments
passed in share the same user. This is a critical assumption that I feel
merrits a validation.
An error will be raised with the ids of the installments which were
attempted to be consolidated.
|
|
This job is responsible for creating a consolidated installment from a
list of installments and processing it.
|
