#karina_ruby-stripeclient
1 messages ยท Page 1 of 1 (latest)
๐ 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/1230640610973716481
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- karina-6458_code, 2 days ago, 13 messages
turns out this was not an rspec issue. but rather just a stripe ruby gem issue
Oh? Just to be clear, do you still need help?
just informing of a bug, and i was hoping to ask if there is a way to rip the stale client out of given stripe objects so that i can do "existing_client.request" rather than "Stripe::StripeClient.new.request"
or if perhaps there would be a more standard way to achieve the above that i'm missing?
What are you trying to do exactly? I see the first line is trying to retrieve a Subscription; I take it you're passing a Subscription ID in the request parameters. What are you trying to do with the second line?
those are the reproduction steps. In my case actual case, my code only has a handle on the stripe subscription object. and i need to make a change to it. I am capturing the response because in this case i want to explicitly ignore all incoming stripe events that spawn from that request.
I would prefer not to do a raw "Stripe::Subscripion.update(id, params, {api_key: ..})" call because my system needs to talk to many stripe instances and knowledge of which particular instance (and therefore which api key) i need to communicate with is harder to get at this point
๐ I admit I haven't really done that code with that SDK in a while. Not entirely sure I follow why you expect there to be a return value. Can you maybe give a simple end to end full repro?
karina_ruby-stripeclient
stripe_object = Stripe::Subscripion.retrieve(...)
stripe_object, response = Stripe::StripeClient.new.request { stripe_object.save(...) }. # here response is nil
stripe_object, response = Stripe::StripeClient.new.request { Stripe::Subscription.update(...) }. # here response is present
I'm sorry this is super confusing and not runnable real code ๐
what does # here response is present mean? That it works? That you expect this to work but it doesn't?
i expect line 2 to return a response, but it doesn't
when running it like line 3 it works
do you want me to insert ids to make it runnable?
I mean ids won't really help since they only work on your account with your key. But yes I was hoping you could write an end to end full script that shows the issue for anyone if possible.
I'm trying to figure out why you're even doing a .save() in that function when this has been deprecated for many years
Gotcha, so yeah we added the update() approach years ago and .save() has always had a lot of history/quirks and is highly discouraged
so if the issue is specific to .save() I'm not surprised the response isn't stored
because that one updates the stripe_object in place, it's a bit of a weird pattern
update on the class?
on that local variable, not the class
yep that
hm. so is there a way to get the api key out of the object?
why do you want the API key? ๐
because my app talks to many instances of Stripe, we always have to send the api key when using the class methods
Yeah I'm sorry you're losing me a lot not, it feels like trying to do a lot of magic when you should know which client to use for which resource you're accessing/using
i can get it by other means, but i was hoping to avoid it and keep this service class clean
I thought it worked fine with .update() though so I don't get the problem. Just never use .save()
yeah, i will look into dropping all instances of .save()
yeah I don't think there's a way to get the client logic you're using to work with .save(). But I also don't think you should ever use that approach to re-extract API keys either
k, sounds good, i'll go rearchitect this class in so that we pass the appropriate client in down from the top bits of code that know about which client to talk to
๐