-
Notifications
You must be signed in to change notification settings - Fork 93
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
pending_subscription node removal #283
Comments
I don't think you need to worry about the pending_subscription when submitting immediate changes. It's really just there so you know what the upcoming change will be. My recollection is that the pending changes will be discarded in favor of what ever immediate changes you submit. So there shouldn't be any need to null out those values. Are you seeing any behavior that makes you think otherwise? |
After making a call to updateImmediately, I still saw the Tested it just now and I am in fact seeing the behaviour you just described Just needed to get a fresh copy of the subscription, since the version used Long story short: always make a new API call to see changes take their full On Nov 2, 2016 1:47 PM, "andrew morton" notifications@github.com wrote:
|
Okay great. Yeah I now picture how that data would linger in the original object and make it super confusing. For future reference when you make changes to an object, only the modified properties are submitted. It would then refresh the values that came back from the server but for something like a removed child object like pending_subscription, it wouldn't be in the response and wouldn't be overwritten. Sounds like it's okay to close this. |
A new project is being set up to require that if a reduction to the subscription is made, those changes are made at renewal, while increases are made immediately.
In the current API, if you updateAtRenewal, a pending_subscription node is attached to the subscription. If then at a later point I wish to updateImmediately, the pending_subscription node is left alone. This leads me to believe that updateAtRenewal could then, at renewal, overwrite all changes that were made to the subscription after the pending_subscription node was added.
Is there a clean process for using the API to remove this pending_subscription node before updating the subscription, that would propagate correctly through to Recurly?
Currently, I have been testing setting the subscription's pending_subscription attribute to null if I'm in the process of creating an updateImmediately change to the subscription. This seems to work and makes the subscription look as expected in the Recurly interface, but I'm thoroughly unsure of any long lasting effects that could have.
The text was updated successfully, but these errors were encountered: