google-nomulus/core
Ben McIlwain dc9d9158d8
Don't write TX records for domains deleted in autorenew grace period (#244)
* Don't write TX records for domains deleted in autorenew grace period

When the project was originally being designed, we envisioned have a purely
point-in-time architecture that would allow the system to run indefinitely
without requiring any background batch jobs. That is, you could create a domain,
and 10 years later you could infer every autorenewal billing event that should
have happened during those 10 years, without ever having to run any code that
would go through and retroactively create those events as they happened.

This ended up being very complicated, especially when it came to generating
invoices, so we gave up on it and instead wrote the
ExpandRecurringBillingEventsAction mapreduce, which would run as a cronjob and
periodically expand the recurring billing information into actual one-time
billing events. This made the invoicing scripts MUCH less complicated since they
only had to tabulate one-time billing events that had actually occurred over the
past month, rather than perform complicated logic to infer every one-time event
over an arbitrarily long period.

I bring this up because this architectural legacy explains why billing events
are more complicated than could otherwise be explained from current
requirements. This is why, for instance, when a domain is deleted during the 45
day autorenewal period, the ExpandRecurringBillingEventsAction will still write
out a history entry (and corresponding billing events) on the 45th day, because
it needs to be offset by the cancellation billing event for the autorenew grace
period that was already written out synchronously as part of the delete flow.

This no longer really makes sense, and it would be simpler to just not write out
these phantom history entries and billing events at all, but it would be a
larger modification to fix this, so I'm not touching it here.

Instead, what I have done is to simply not write out the DomainTransactionRecord
in the mapreduce if the recurring billing event has already been canceled
(i.e. because the domain was deleted or transferred). This seems inconsistent
but actually does make sense, because domain transaction records are never
written out speculatively (unlike history entries and billing events); they
correspond only to actions that have actually happen.  This is because they were
architected much more recently than billing events, and don't use the
point-in-time hierarchy.

So, here's a full accounting of how DomainTransactionRecords work as of this commit:
1. When a domain is created, one is written out.
2. When a domain is explicitly renewed, one is written out.
3. When a domain is autorenewed, one is written out at the end of the grace period.
4. When a domain is deleted (in all cases), a record is written out recording the
   deletion.
5. When a domain is deleted in the add grace period, an offsetting record is
   written out with a negative number of years, in addition to the deletion record.
6. When a domain is deleted in the renewal grace period, an offsetting record is
   likely written out in addition.
7. When a domain is deleted in the autorenew grace period, there is no record that
   needs to be offset because no code ran at the exact time of the autorenew, so
   NO additional record should be written out by the expand mapreduce.
   *THIS IS CHANGED AS OF THIS COMMIT*.
8. When a domain is transferred, all existing grace periods are cancelled and
   corresponding cancelling records are written out. Note that transfers include a
   mandatory, irrevocable 1 year renewal.
9. In the rare event that a domain is restored, all recurring events are
   re-created, and there is a 1 year mandatory renewal as part of the restore with
   corresponding record written out.

So, in summary, billing events and history entries are often written out
speculatively, and can subsequently be canceled, but the same is not true of
domain transaction records.  Domain transaction records are only written out as
part of a corresponding action (which for autorenewals is the expand recurring
cronjob).

* rm unused import
2019-08-30 12:04:35 -04:00
..
gradle/dependency-locks Upgrade google-auth-library-java to latest version 2019-06-18 17:27:21 -04:00
src Don't write TX records for domains deleted in autorenew grace period (#244) 2019-08-30 12:04:35 -04:00
build.gradle Remove the "showAllOutput" property from the build (#247) 2019-08-30 10:43:07 -04:00
Dockerfile Build docker image of nomulus tool (#142) 2019-07-16 20:18:44 -04:00