This used to be a more likely codepath, before we introduced
Customer.has_billing_relationship. It is no longer literally impossible to
hit this race condition, so I'm not deleting the code, but it's unlikely
enough that it's not worth figuring out how to test it.
Already better tested by the upgrade and downgrade tests using mock_stripe.
Note that the line that was removed is actually not possible to reach, since
canceled subscriptions aren't shown on the Customer object.
Also fixes a bug in process_initial_upgrade. If you have a card on file
(e.g. from a previous subscription), and try to upgrade by billing by
invoice, neither the if nor the elif condition applies.
Was hoping to do this after adding timestamp normalization to
normalize_fixture_data, which would have turned this into a <10 line
diff. There is a potentially material change in this API upgrade though
(around how invoices are handled), so just doing it now.
Without the cast mypy raises the following error:
Incompatible return value type (got "Callable[..., Any]",
expected "CallableT")
This is a known issue: https://github.com/python/mypy/issues/1927
This makes a few other changes to the fixtures as well. Most are from API
updates, though I'm not sure why "Zulip Cloud Standard" got changed to
"Zulip Cloud Premium".
[Substantial edits by Rishi Gupta]
This means you'll need access to our Stripe API key to add new fixtures.
Will be undone eventually, but having this in place will make it easier to
finish the mock.patch to mock_stripe migration.
This will improve both the maintainability and accuracy of the fixture
data. It also makes it less scary to upgrade Stripe API versions.
[With significant changes by Rishi Gupta.]