Bug
In RecurringPaymentCommandHandler.scala, the UpdateRecurringCardPaymentRegistration handler constructs the RecurringPaymentRegisteredEvent using the original recurringPayment object (with IN_PROGRESS status) instead of the updated one with the new cardStatus (e.g., ENDED).
File: core/src/main/scala/app/softnetwork/payment/persistence/typed/RecurringPaymentCommandHandler.scala line 300
RecurringPaymentRegisteredEvent.defaultInstance
.withExternalUuid(paymentAccount.externalUuid)
.withRecurringPayment(recurringPayment) // ← BUG: uses pre-update recurringPayment
Impact
Any downstream EventProcessorStream that reads RecurringPaymentRegisteredEvent and checks cardStatus to detect cancellation (e.g., Payment2LicenseProcessorStream in the license-server) will never see ENDED — it always sees the old status (IN_PROGRESS).
This breaks the subscription cancellation → license revocation flow.
Fix
.withRecurringPayment(recurringPayment.withCardStatus(result.status))
Found during
Story 5.11 Stripe integration testing in softclient4es-license-server.
Bug
In
RecurringPaymentCommandHandler.scala, theUpdateRecurringCardPaymentRegistrationhandler constructs theRecurringPaymentRegisteredEventusing the originalrecurringPaymentobject (withIN_PROGRESSstatus) instead of the updated one with the newcardStatus(e.g.,ENDED).File:
core/src/main/scala/app/softnetwork/payment/persistence/typed/RecurringPaymentCommandHandler.scalaline 300Impact
Any downstream
EventProcessorStreamthat readsRecurringPaymentRegisteredEventand checkscardStatusto detect cancellation (e.g.,Payment2LicenseProcessorStreamin the license-server) will never seeENDED— it always sees the old status (IN_PROGRESS).This breaks the subscription cancellation → license revocation flow.
Fix
Found during
Story 5.11 Stripe integration testing in softclient4es-license-server.