pending_subscription node removal

[ram651]

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.

[drewish]

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?

[ram651]

After making a call to updateImmediately, I still saw the
pending_subscription nested element, but I now realize I should then make a
call to reacquire the subscription via the API to check for the pending
object.

Tested it just now and I am in fact seeing the behaviour you just described
of updateImmediately blowing away any pending changes.

Just needed to get a fresh copy of the subscription, since the version used
with updateImmediately still had all the pending changes stored, as per its
state in the last API call to grab the subscription.

Long story short: always make a new API call to see changes take their full
effect.

On Nov 2, 2016 1:47 PM, "andrew morton" notifications@github.com wrote:

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?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#283 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIZ5Ig7ZB5qF8ScBA2rxXui1Z9BA1a30ks5q6PbegaJpZM4KnlTT
.

[drewish]

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.