mirror of
https://github.com/google/nomulus.git
synced 2025-07-26 04:28:34 +02:00
dc9d9158d8
* 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 |
||
|---|---|---|
| .. | ||
| gradle/dependency-locks | ||
| src | ||
| build.gradle | ||
| Dockerfile | ||