New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing subscription's plan ignores quantity #388

Closed
alanhamlett opened this Issue Jan 10, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@alanhamlett

alanhamlett commented Jan 10, 2018

Description

When a customer has an existing subscription with quantity 2 and plan plan1, updating the subscription's plan always uses quantity 1.

Example

subscription = stripe.Subscription.retrieve({SUBSCRIPTION_ID})
assert subscription.plan == 'plan1'
assert subscription.quantity == 2
subscription.plan = 'plan2'
subscription.quantity = 2
subscription.save()

subscription = stripe.Subscription.retrieve({SUBSCRIPTION_ID})
assert subscription.quantity == 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

Stripe logging shows only plan_id is sent to the api when calling subscription.save().

@remi-stripe

This comment has been minimized.

Show comment
Hide comment
@remi-stripe

remi-stripe Jan 11, 2018

Contributor

@alanhamlett Thanks a lot for the report! I think that the issue here is that quantity does not change so it's not sent to the API. On the other hand, server-side the API resets quantity to 1 when you change the plan id.

We'll likely need to special-case this in the library. Assigning to @ob-stripe who was looking into it!

Contributor

remi-stripe commented Jan 11, 2018

@alanhamlett Thanks a lot for the report! I think that the issue here is that quantity does not change so it's not sent to the API. On the other hand, server-side the API resets quantity to 1 when you change the plan id.

We'll likely need to special-case this in the library. Assigning to @ob-stripe who was looking into it!

@ob-stripe

This comment has been minimized.

Show comment
Hide comment
@ob-stripe

ob-stripe Jan 12, 2018

Contributor

This issue is caused by the fact that the Python library will only register an attribute as an unsaved value when it is updated with a different value:

>>> s = stripe.Subscription.retrieve('sub_...')
>>> s.quantity
1
>>> s.quantity = 1
>>> s._unsaved_values
set([])
>>> s.quantity = 2
set(['quantity'])

This behavior is different from most of our other libraries, where attributes are registered as unsaved on assignment, regardless of the new value. E.g. in Ruby:

[1] pry(main)> s = Stripe::Subscription.retrieve('sub_BqStq3lplpOQKs')
[2] pry(main)> s.quantity
=> 1
[3] pry(main)> s.quantity = 1
[4] pry(main)> s.instance_variable_get(:@unsaved_values)
=> #<Set: {:quantity}>

I'll push a fix, but in the meantime a simple workaround is to set a different value, then immediately set it back. E.g. in your case:

subscription.plan = 'plan2'
subscription.quantity = 42
subscription.quantity = 2
subscription.save()
Contributor

ob-stripe commented Jan 12, 2018

This issue is caused by the fact that the Python library will only register an attribute as an unsaved value when it is updated with a different value:

>>> s = stripe.Subscription.retrieve('sub_...')
>>> s.quantity
1
>>> s.quantity = 1
>>> s._unsaved_values
set([])
>>> s.quantity = 2
set(['quantity'])

This behavior is different from most of our other libraries, where attributes are registered as unsaved on assignment, regardless of the new value. E.g. in Ruby:

[1] pry(main)> s = Stripe::Subscription.retrieve('sub_BqStq3lplpOQKs')
[2] pry(main)> s.quantity
=> 1
[3] pry(main)> s.quantity = 1
[4] pry(main)> s.instance_variable_get(:@unsaved_values)
=> #<Set: {:quantity}>

I'll push a fix, but in the meantime a simple workaround is to set a different value, then immediately set it back. E.g. in your case:

subscription.plan = 'plan2'
subscription.quantity = 42
subscription.quantity = 2
subscription.save()
@brandur-stripe

This comment has been minimized.

Show comment
Hide comment
@brandur-stripe

brandur-stripe Jan 12, 2018

Member

Pushed a fix with @ob-stripe's patch in 1.77.1. Thanks @ob-stripe / @remi-stripe!

Member

brandur-stripe commented Jan 12, 2018

Pushed a fix with @ob-stripe's patch in 1.77.1. Thanks @ob-stripe / @remi-stripe!

@alanhamlett

This comment has been minimized.

Show comment
Hide comment
@alanhamlett

alanhamlett commented Jan 13, 2018

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment