Introduce last amendment check

[shtukas]

(This PR description is the comment that I put at the top of the new case class.)

Class ZuoraSubscriptionAmendment is introduced to detect whether or not there has been an amendment on a subscription between the estimation step and the amendment step.

The check is introduced to prevent a problem by which, at least for the digital products we have scheduled for price rise in 2023, (where people would be notified by email, and where the subscriptions can be managed online), there was also possibility for user to perform user-triggered subscription mutations online (for instance product changes), which would not be known to the engine and which would then be lost and/or overridden by the engine at amendment step. We then decided that the engine would not proceed with any price rise if there were amendments on the subscription between the estimation step and the amendment step.

This logic solves the immediate problem, but such a simple check is too crude and too inefficient, as it will prevent some subscriptions from being migrated if they undergo mutations (amendments) that have nothing to do with user journeys. In an ideal world we would retrieve the entire collection of amendments, analyse the recent ones and make a determination on whether or not a price rise can happen.

Unfortunately Zuora, as far as we know, only offers us the retrieval of the last amendment. This is enough for the check since we can then compare the date of estimation with the effective date of the amendment (which seems to coincide with the date the amendment was created). But, this is clearly not enough for the type of thorough evaluation that would lead to a better check (without false positives).

1. At the moment we only need the effectiveDate. This is the reason why this first version of the class only carries that one attribute.

2. It will be great if in the future the following is done

• 2.1 Find a way to retrieve more amendments, ideally the entire sequence of amendments of a subscription.
• 2.2 Implement an analysis of that sequence to provide a better answer to the question: Should the engine perform the scheduled price rise on the corresponding subscription.

Together with ZuoraSubscriptionAmendment we introduce

• case class IncompatibleAmendmentHistory, and
• checkMigrationRelevanceBasedOnLastAmendment in the amendment handler

Note: This version is going to fail noisily when the amendment condition occurs. This is on purpose. Once that happens, we will edit the check to cause the intended IncompatibleAmendmentHistory failure mode.

[kelvin-chappell]

👍

[kelvin-chappell]

I think Zuora also refers to subscription numbers as subscription names in some of their docs as well! (And also possibly the UI as well somewhere)

[shtukas]

Tiny observation in the wild (PROD)

We processed this subscription this morning (from the supporter+ migration)

The log specified that the ZuoraSubscriptionAmendment object was

In order to validate that we just needed to look up the subscription in Zuora

Where we see that indeed the last amendment before the engine's mutation happened on 2023-03-23

We also need to check how that date relates to the estimation date. The record in the Dynamo table is

The estimation happened after the last amendment.

[shtukas]

Failure case: