12/15/2016 8:59:48 AM
<pierre@mouraf.org>
|
12/15/2016 8:58:23 AM
sure the link invoice-payment is updated after fixing a transaction
from SUCCESS to PAYMENT_FAILURE.
To do so, the fixPaymentTransactionState implementation now updates the
payment attempt associated with the transaction being fixed.
This also fixes the shortcut in IncompletePaymentAttemptTask, where control
plugins weren't called during the completion.
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 6:15:38 AM
that we won't attempt any retry in that case, because the transition was
triggered by an API call.
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 5:26:06 AM
invoice send an InvoicePaymentErrorInternalEvent event upon processing
a PENDING payment: this is used as a trigger for Overdue (which doesn't listen
to pure payment events anymore, but just InvoicePaymentInfoInternalEvent / InvoicePaymentErrorInternalEvent).
The name could be a bit misleading but I'm not sure it's worth introducing another
internal InvoicePaymentPendingInternalEvent event for this. The name does match
the state on disk though (success = false while the payment in PENDING).
This internal event will be sent as an INVOICE_PAYMENT_FAILED on the external bus.
Listeners should make sure to retrieve the full payment to act on it (which is
the best practice anyways).
If the payment transitions to success, InvoicePaymentInfoInternalEvent is
subsequently sent (INVOICE_PAYMENT_SUCCESS on the external bus).
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/14/2016 4:11:17 PM
payments
Make sure the InvoicePayment control plugin supports PENDING payments.
To make it work, this patch:
* implements notifyPendingTransactionOfStateChangedWithPaymentControl
* introduces a new NOTIFICATION_OF_STATE_CHANGE ControlOperation
* ensures that requestData is always populated in CallableWithRequestData (otherwise locks are not re-entrant)
Note that the control state machine already supported the PENDING state (see 179d67741ea89506acccdfb21ad58960d5939e9b).
There is no separate state in that case, the payment attempt ends up in a SUCCESS state while the payment is PENDING. No new attempt is created when completing
the payment through the control APIs.
More work is required around testing:
* Verify Overdue is notified while the payment is PENDING
* Verify a transition PENDING -> PAYMENT_FAILURE schedules retries
* Verify integration with the fixPaymentTransactionState AdminApi
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/14/2016 12:32:39 PM
https://github.com/killbill/killbill/issues/674.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/13/2016 7:07:23 AM
towards lock failures
This patch also fixes the injection of the payment tasks and associated test setup.
This fixes https://github.com/killbill/killbill/issues/675.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/13/2016 6:06:51 AM
a follow-up of 17307b4e2834d3d254a85961e14a00def4aa86a3.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/16/2016 9:10:22 PM
Add more XML constraints (required=true) when possible (might break CatalogUpdater template version)
* Add safety for non required array by initializing such values with zero length array
|
12/13/2016 12:34:32 AM
a timeline for a subscription that has an empty <fixedPrice> we get an NPE.
We could fix the issue in SubscriptionJson (line 392) but fix seems better in the catalog to ensure that any fixedPrice will
have a non null InternalPrice.
|
