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.
There is no attribute called plan_interval. The reason
this was missed by mypy is moost likely due to us using
Any instead of Subscription in extract_current_subscription.
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.
The actual implementation of the change will be a cron job that runs once a
day and generates invoices for anyone with an account_balance > 0.
There are currently no tests for that part of the flow, so no tests had to
change.
This will make it easier to mock the calls in our new stripe mocking
framework. I believe the two forms are equivalent, assuming the Stripe
Python bindings aren't doing anything crazy. And if not, well hopefully our
new testing framework will catch it :).
[Idea originally from Vishnu KS.]
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.]
Rishi Gupta
Vishnu Ks