#aaron_code
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/1286237494278623234
đ 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.
- aaron_unexpected, 11 hours ago, 8 messages
This is the code that checks
if (responseData["error"] === "invalid_grant") {
this.user = await weivData.update("Users", {
...this.user,
stripeRefreshToken: null,
stripeAccessToken: null,
stripeAccessTokenExpiresAt: null,
stripeUserId: null
});
EmailClient.sendStripeDisconnectedEmail(this.user);
console.error("StripeInvalidGrantError", responseData);
throw new StripeInvalidGrantError(responseData["error_description"]);
} else {```
Randomly at least once a day users get hit with a random invalid_grant error code in a request, which wipes their data from their user in our system
It's like it gets invalidated or something, but we can't track it down
hi! what API is this calling? where does responseData come from?
by which you mean connect.stripe.com/oauth/token?
do you have a specific example with an exact UTC timestamp and the IP address of your server when making the request
I can check my events
req_XpIJZAc9jvxJSr I have that request ID
another one req_6EYGeJDokRZVQW
6:01 AM
Sep 17, 2024
I have the timestamp but the IP is dynamic so it could be anything
thanks. Hmm unfortuntely we redact the params in the logs so I can't see if what you passed was actually a refresh token or not.
damn
this was the response body
"error": "invalid_grant",
"error_description": "Refresh token does not exist: rt_Qqb********************************"
}```
But like I have no idea how we would even get a refresh token that doesn't exist
its saved to their profile when they auth, and they're able to make API calls throughout the app, then randomly we get hit with this error
its like its being revolked or something
I also don't see any Application deauthorized events in the Stripe account (the customer or our app Stripe)
that error can happen if the secret key you used on the request is not the key of the platform/app that the token was issued to
if it's not that, maybe it's a race condition, hard to say. That error is simply that we looked up the token, using your authentication for the request, and couldn't find it.
hmm, the only thing i can think of is the key being passed as undefined or an unresolved promise. would we get an entirely different error if we provide no key at all? or will it attempt the request
I think it would fail earlier than this error
that request came from acct_1PUxoEP2tTL3BoXM Pr******e App
Okay yeah that's the correct account
What about this?
"error": "invalid_grant",
"error_description": "Authorization code does not exist: undefined"
}```
Would this be indicative of the platform account passing an invalid key?
I see this error in my logs
that would mean you passed an empty &authorization_code= in the request
apologies for my ignorance - is that the code that would be passed from the App account? like what is that code used for
i get little confused with all the tokens/codes names
that could be anything really, like a user directly visiting your final URL without actually going through the installation flow
yeah definitely
this is really the issue.
so you're thinking race condition maybe?
as for the refresh_token error, I don't know, maybe it's a bug like a race condition where the token is not saved in our database. I'd open a support ticket with as many examples as you can and hopefully someone can investigate it. The observability/logs for these APIs is really bad(because they were only used for legacy Connect, Connect wanted to stop using OAuth, but then Apps built on top of it).
I'd suggest at least catching the error and retrying it after a short backoff, that could help
I think as long as you specifically catch invalid_grant it's safe to retry the request(it's not safe to retry a network error on this endpoint though since reusing the token will remove the connection)
When a token isn't found, is that the same error description as if a token got invalidated and is trying to be used?
If so it is probably a race condition, but otherwise it not being found yeah that could be deeper and worth reaching out for
no, it's a specific erorr like 'This authorization code has already been used. All tokens issued with this code have been revoked.' I think. I'm not 100% if that can happen when using refresh_tokens. Sorry, I have almost no institutional knowledge on refresh tokens, I spent years telling people to never use our OAuth endpoints and just use the Stripe-Account header to authenticate requests on connected accounts and avoid the whole complexity, but now Apps makes you use these endpoints I tried to ignore for years
hahahaha
yeah the setup for OAuth on Stripe Apps was definitely something we wanted to avoid but seemed unavoidable
damn hmm
I do recall that error that makes sense
Not that you aren't doing amazing but is there anyone that might have insight into refresh_tokens in this context that could chime in?
I aksed my team but I would suggest a support ticket instead. In the meantime what is the account ID of the account who installed the App that your earlier example of req_XpIJZAc9jvxJSr was related to?
"acct_1PentdCDIXxitiYy"