Remove _ensure_full_coverage step from invoicing #35503
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Technical Summary
SAAS-16270
In the past, a project space having no assigned subscription would mean they were on the Community plan. This meant that, when generating invoices, we would also have to check if there were periods of no subscription and count them as Community for invoicing purposes (because Community plans can still incur charges). This would happen through
_ensure_full_coverage
, by creating a backdated Community plan subscription for the invoicing period.More recently, all project spaces are always assigned a subscription even when there is "no" subscription -- Community when signing up initially, or Paused if they were previously on a subscription that expired or went unpaid. This means that
_ensure_full_coverage
is no longer relevant and can be removed, along with tests for it. Some other invoicing tests have been tweaked to account for the change.Safety Assurance
Safety story
I've dug a bunch into this and other subscription-related code and become confident that under no reasonable circumstances can a project space end up without a subscription these days. Changes to invoicing can be fairly high-risk, however the worst scenario here is likely that a project space which was on "no subscription" and actually should have been on "Community" does not get invoiced for charges.
There are currently ~300 "active" project spaces on production with no assigned subscription, though none have submitted any forms in the past 30 days, and it seems that none of these spaces ever had a subscription, likely indicating that subscription setup failed during project creation. The fact that they have never had a subscription also means they have never had enough use to incur charges on a Community plan (or a backdated subscription would have been created via
_ensure_full_coverage
), so leaving them be is probably harmless. If there is concern about these, I can put together a script to move all of these project spaces explicitly to Community.Automated test coverage
There is good test coverage of invoicing between
test_invoicing
andtest_invoice_factory
, one case of which I actually removed because it seemed to overlap entirely between the two.QA Plan
Not planning QA. Planning to put this on staging for a bit (through the end of the month, so the invoicing task can run as usual) and see that results look normal. All automated testing shows that it should be fine.
Rollback instructions
Labels & Review