#ruin_code
vale ridgeBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1217513461240561664
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
potent orchid
obtuse sorrelBOT
potent orchid
I want to understand motivation for this change and how I can achive similar behaviour?
or are there any alternatives
remote pagoda
I cannot tell you the motivation (I'm not invovled in SDK decisions) but you should be able to omit the parameter entirely and get the same behavior.
Following our API reference doc https://docs.stripe.com/api/subscriptions/list
For the status parameter:
If no value is supplied, all subscriptions that have not been canceled are returned.
potent orchid
If I don't provide status, it will return all?
remote pagoda
Oh you also want Subscriptions that are canceled?
remote pagoda
this is not describing that
What is "this" and "that" in the quoted sentence?
Also, please just copy/patse text. Screenshots are not very useful to us here.
potent orchid
sry for not beaing clear, the link that I've provided is saying that "all" as a keyword is not a valid one
from the stripe-go sdk:
// The status of the subscriptions to retrieve. Passing in a value of `canceled` will return all canceled subscriptions, including those belonging to deleted customers. Pass `ended` to find subscriptions that are canceled and subscriptions that are expired due to [incomplete payment](https://stripe.com/docs/billing/subscriptions/overview#subscription-statuses). Passing in a value of `all` will return subscriptions of all statuses. If no value is supplied, all subscriptions that have not been canceled are returned.
looking that how and why are we using listing for all customer subs, and it seems the only reason for that is to check if some subscrion had trial active on it. is there any other way we can check if trial has been used for a customer?
remote pagoda
Hmmm let me see if I'm understanding you correctly.
You want to retrieve all Subscriptions with active trials? Or you want to check for specific Customers?
potent orchid
I want to see if there are any historical customer subscriptions that had trial active on them. (having .TrialStart && TrialEnd > 0) So I can show user if he can activate the trial or not.
basicly, did he used the trial in the past.
remote pagoda
Okay so you have a Customer and you want to see if they have ever had a free trial period on a Subscription in the past?
potent orchid
Yes
remote pagoda
Okay so that is why you need all Subscriptions for that Customer regardless of status. So you can check the trial properties.
potent orchid
(currently, we are iterating over all subscriptions for a single customer and checking if there was free trial period on a subscription)
yes
remote pagoda
Yes that makes sense, given what we have available.
Honestly, to me, this seems like a lot of effort and a round-about way to get some data that could be stored more simply.
I am still looking into your question but I have another suggestion as well
potent orchid
I know, initially taught about adding column in our DB, but then "what happens if trial activation fails" "how do we rollback the DB" etc. etc. it is much easier to keep the state of trial activate at the source (your db)
remote pagoda
I recommend that, when your integration creates a Subscription with a free trial for a Customer, you update the Customer object metadata field to indicate that they had a Subscription with a free trial period. You could even store the Subscription ID to make it easier to look up the Subscription later.
To address the activation failure issue, you could use webhooks
If you listen for the customer.subscription.created event, you could check the Subscription object that is returned for trial period data and then update the Customer object if that data is present. https://docs.stripe.com/api/events/types#event_types-customer.subscription.created
potent orchid
agreed, I can do that for future subs, but not for historical. I mean i can, just I still need to list all subscription in order to populate that metadata.
remote pagoda
Yeah, I understand that
I've raised the question with the SDK team and I'm reviewing other parameters to see what can achieve the same outcome for you
potent orchid
hmm, thinking... what is the fastest way I can "fix" this, and later improve it to be more optimal 🤔
remote pagoda
The fastest would be to make 2 Subscription List requests. One where you omit the status parameter and one where you specify canceled
potent orchid
Yeah, that can work, but I can already sense PR comments like "code smell" "tech debt" "hacky approach" 😅
inital approach, with metadata is better, but I need to do a backfill of the data retroactivlly
thank you for help, really appriciated 🙏
remote pagoda
Yeah I understand it is less than ideal. So PR motivation like "temporary patch" might be in order 😅
potent orchid
additionally I can use old version of SDK just for this single query, that can work also until I write a backfill script\
remote pagoda
True
potent orchid
Yeah I understand it is less than ideal. So PR motivation like "temporary patch...
with a capital letters TODO "this is bad, it is a hack, we are going to remove it" 😂
remote pagoda
I'm not really familiar with Go runtime isolation but you could keep the logic that governs the Subscription List call running on an older version until you are ready to upgrade
potent orchid
yeah, it is pretty easy to do:
obtuse sorrelBOT
potent orchid
here is my email, when you get back from the SDK team
filip@tenderly.co
I would probably not need any more assistance, this hacky approach will probably work. I'm trying it now.
remote pagoda
I can't send a direct email to you. I recommend you write in to Support here https://support.stripe.com/contact and repeat your question about the parameter changes in the SDK versions. That way we can get back to you once we know.
potent orchid
ok, will do, I can wait a bit longer
also, what if I just send "all" (without using your predefined types), will that work?
remote pagoda
I'm not sure, you can test this yourself.
Could you test this and let me know? params.Status = stripe.String("all")
potent orchid
will do, just I've couple of meetings right now
will get back to you a bit later, sry
remote pagoda
Okay my colleague just pointed out that what was removed what the API response. You should just pass a String like in the snippet above. The SubscriptionStatusAll wasn't a value we intended to be passed as a parameter in the first place. So using params.Status = stripe.String("all") is the intended pattern. We intend you pass all parameters as strings and not string-type enums