#philipp_api
night martenBOT
👋 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/1298394262496481312
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
nocturne hollow
Are you aware of any changes made to your environment within the last hour?
spiral matrix
There were no changes
nocturne hollow
Got it. As far as we can tell, there's nothing particular to the Go library that would indicate that this is an issue with the library or with the Stripe API
If there's anything else you can collect about the requests that result in this error or what exactly is returning that error, that would be helpful
spiral matrix
Thanks for checking. Mostly, I'm wondering if these requests even made it to the Stripe API, or if they were hijacked on path, and subject to a TLS downgrade attack.
nocturne hollow
I don't see request IDs on my end so don't think these made it to Stripe. Ideally, I recommend working with your networking team on this to see if you can trace the route of these requests
spiral matrix
The request ID is part of the HTTP layer though, no? If the connection fails at the TLS layer, the request ID wouldn't make it through. Do you happen to have logs that show TLS protocol mismatches?
karmic delta
👋 will take over for a bit as I was looking in parallel. You're right that there wouldn't be a request id because it wouldn't have reached a layer in our own code where one would be generated.
We should still have some trace about this though in our logs. I was looking at every API request made on /v1/plans/plan_H0mxLzrETtSadm in the past 4 hours and every single one made with Go succeeded. You had a handful of failures due to missing an API key but it was using raw go http requests or even a browser so i assume you might have tried to debug
spiral matrix
That's right, the failed requests were because of manual debugging
karmic delta
It is still possible that because the TLS negotiation failed we have no logs but that's where we'd need more actionable details unfortunately to trace it, especially because you seem to make so many requests to the same exact API with the same exact Plan id (which is quite abnormal)
So I think at this point we'd need a way to at least narrow down our search if possible
spiral matrix
Got it. If it helps, I can provide the timestamps of the six or so requests that resulted in the TLS error
karmic delta
One possibility: write a script that will attempt to retrieve a Plan but change the id every time like plan_koopajah1, ``plan_koopajah2`, etc. until you hit that error and log the id/index. Then I can see if I find logs for it, or the one right before.
The timestamp could help but you made like 1.2k requests for one specific Plan in the past 4 hours 😅
spiral matrix
Yikes! Thanks for your help – we'll keep that in mind if this happens again.
karmic delta
Any chance you can run a script to try again? Also it'd help of you log the IP address of the server since you seem to use a large number of IPs, that would allow us to pinpoint the issue faster
spiral matrix
That's difficult because I can't spawn a shell in the kubernetes pod that's running the affected service. Logging the IP address is a good idea though, right
karmic delta
yeah it's going to be tough to help if you can't access that server/environment and run a long running script to try and narrow down the issue.
It's definitely surprising and I'm hopefuly it's just some configuration issue on your end but the error shape is a bit worrying. You use TLS 1.3 as far as I can tell and it almost felt like the rejected requests are due to our server saying "sorry I only support TLS 1.2" which shouldn't be a thing
spiral matrix
Right, that's why I was wondering if these requests were hijacked and ended up at some rogue web server. Somewhat unlikely I assume but the best explanation I have right now
karmic delta
yeah seems unlikely to have requests hijacked like that though
spiral matrix
Anway, that was still helpful. We'll try to add some extra logging so you have more to work with if this happens again
karmic delta
sounds good! Thanks for bearing with us!
spiral matrix
Sure thing, thanks again and take care