#newtreyes_error
analog patrolBOT
👋 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/1351510995255824474
📝 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.
- newtreyes_api, 5 days ago, 89 messages
winged whale
Hi @wary birch
wary birch
Can you share the ID (req_xxx) of the API request? https://support.stripe.com/questions/finding-the-id-for-an-api-request
Or the Dispute ID?
Is this a consistent issue? Sporadic? Sounds like a network connectivity issue
winged whale
Here's an example: 'dp_1R3xzeIJwkxnVmNVUXbUwqyM'
consistent if I run 2 consecutive tests
There is no request id
wary birch
I don't know what 'tests' entails
winged whale
I am running integration tests
both of those tests update dispute metadata as part of their logic
wary birch
There is no request id
As I suspect, it's not reaching that later of the API so indicative of a network issue
wary birch
Generally recommendation is to not run automation tests against the API
winged whale
Let me give you a request id that worked: req_0s1xGavkWeWw4t
wary birch
but why is this same logic working for the first test then?
I don't know, as I said it's indicative of a network/connectivity issue in your environment. Maybe the 2nd request uses a different IP address that you block? https://docs.stripe.com/ips
winged whale
This same type of request runs without a problem the first time
then it fails the second time
No IPs are being blocked
Anything else you could think of?
I've been seeing this behaviour consistently the last couple of days
I just tried avoiding it but this time, I wanted to see if there was something else to be done
It looks as if it is retried it then works
wary birch
What kind of environment is your test suite running in?
Can you run this script inside that environment: https://github.com/stripe/stripe-reachability
As I said, this points to a network issue rather than an API issue (no known issues right now), so trying to work towards debugging that. If it were even a rate limit issue there'd be an actual error indicating so
winged whale
Yes
wary birch
Yes what?
wary birch
And what were the results?
winged whale
Here
Sorry, I am not trying to be annoying about this. If you think this is an issue from my environment and we should leave it at that, then that's it. I can work around it but I trully don't think this is a connectivity issue as there are several tests running without an issue and this fails consistently.
wary birch
I'd probably recommend you write in to my team at this point and we can investigate this further. It's definitely a network issue of sorts, maybe we're blocking the IP the request originates from etc, or could be a config issue in your CI/env/whatever
I'll DM you a link and it'll come direct to my team. If you can give us info on the environment the errors occur in, IP addresses, etc that'll help
analog patrolBOT
Hello @winged whale, we have sent you a direct message, please check it at https://discord.com/channels/@me/1351516404808941582
- 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.