#smartbettormicah-developer_code
chilly ravineBOT
👋 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/1376930819549171744
📝 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.
- smartbettormicah-developer_code, 4 days ago, 7 messages
mighty path
Full api route
rocky olive
Hello, which line specifically throws that error? Is it a call to a Stripe API?
mighty path
Yes It is the call to create the ephemeral key
ephemeralKey = await stripe.ephemeralKeys.create(
{ customer },
{ apiVersion: "2025-04-30.basil" }
);
rocky olive
If you look at your dashboard logs do you see any examples of that request erroring?
https://dashboard.stripe.com/logs
https://dashboard.stripe.com/test/logs
If you can send me the request ID from that, that will be helpful, otherwise I can try to look it up with your account ID but definitely check your dashboard logs first
rocky olive
Gotcha, can you send me your account ID? (acct_1234) I can try to find these requests in our logs from that
And has this call worked for you before or is this the first time it is being added to this code?
mighty path
Yes it is working for me in my local environment running on port 8081/api/payment-sheet, it is not working on https://oddible--preview.expo.app/api/payment-sheet
I am using my test account, how can I find an account number from that
rocky olive
If you click on the account selector in the upper right and then your name it brings you to a page that lists it out at the bottom. I forget if there is a more straightforward way of checking but that is how I check
https://dashboard.stripe.com/settings/user
Oh or an easy way to get it via the API is to make the account retrieve call without passing an account ID
mighty path
acct_1Nm0vBHM5Jv8uc5M
rocky olive
Looking in to this. Also one more piece of debugging: have you tried running this call by itself to see if it gets the same error? Like if you make a js file that just tries to make this call, print the result, and exit, does that also throw this error for you?
Also I do see that "Unhandled Worker Script Exception" is expo's generic error for unhandled exceptions. If you wrap this call in a try-catch you may be able to see a more descriptive error
mighty path
I am calling it with thunder client directly
ANd still getting that error
Also it is in a try except:
console.log("Creating ephemeral key");
let ephemeralKey;
try {
console.log("Attempting to create ephemeral key with customer:", customer);
ephemeralKey = await stripe.ephemeralKeys.create(
{ customer },
{ apiVersion: "2025-04-30.basil" }
);
console.log("Ephemeral key created successfully:", ephemeralKey.id);
} catch (error) {
console.error("Error creating ephemeral key:", error);
console.error("Error details:", {
message: error instanceof Error ? error.message : String(error),
type: error instanceof Error ? error.constructor.name : typeof error,
customer,
environment: process.env.EXPO_PUBLIC_APP_ENV
});
return new Response(JSON.stringify({
error: 'Error creating ephemeral key',
debug: {
userId,
customer,
environment: process.env.EXPO_PUBLIC_APP_ENV,
errorMessage: error instanceof Error ? error.message : String(error),
errorType: error instanceof Error ? error.constructor.name : typeof error
}
}), {
status: 500,
headers: { 'Content-Type': 'application/json' }
});
}
rocky olive
Is the 500 menitoned by the exception the one that your code is returning here or is this 500 a code that Stripe is returning to you?
mighty path
It is actually not caught by the catch clause, it is returned by the cloudflare worker of the expo api host. It seems like there is an error in the stripe api that causes the await to hang
rocky olive
I'm not that familiar with how expo hosts and cloudflare workers behave here, is that to say that we are throwing an error that is causing this? Or is this potentially that some operation is taking so long that it causes something to be considered hanging? I am trying to figure out what may be going on on the Stripe side
mighty path
I would have assumed that it had nothing to do with stripe except the last line to console log is "Attempting to create ephemeral key with customer:". Implying that it happens with the react native stripe ephemeral key implementation
rocky olive
I think this error may be happening locally on your device, or in the connection between your device and server. I can only see two instances of the ephemeral key creation call erroring out in our logs, and it sounds like you've seen this more than two times
mighty path
Yes I think it is because of the stripe react native package not necessarily the call. Still, fundamentally a stripe error
rocky olive
For preciseness: this call is part of our node library, the RN library can't create ephemeral keys by itself.
I am reaching out to a colleauge for help here. And so just to make sure I understand what you are seeing in your logs, you see "Attempting to create ephemeral key with customer" and then nothing else. You don't see the logging from the catch statement and your server errors with a 500, but it is not the 500 from your code, it is from Firebase's worker not being able to handle some expection that is thrown?
mighty path
Nope no logging after correct
chilly ravineBOT
mighty path
Could it be my version 2025-04-30.basil?
rocky olive
No, we aren't seeing the API call at all, so the API version isn't coming in to play here. Is there a way you can up the verbosity of your worker logs? Because the thing that is hanging seems to be related to the worker, there should be some more detailed error somewhere. The stripe-node library is just trying to make a simple REST request from that call, so it is hard to say what may be hanging before the request even goes out to us
mighty path
Let me see if I can add some more logging. It just seems so internal to the point where it is a package conflict
I am trying to add try catches everywhere but they are not being reflected. It seems like there is a timeout issue in the stripe package itself
rocky olive
We throw a timeout exception in that case though also the timeout is only relevant after the call has been made. Can you see if other stripe-node calls fail the same way if you swap them in to that part of the code? Alternatively if you remove the ephemeral key create call and replace it with returning a hard-coded one does the error go away?
mighty path
Yes one second
No it seems that all of the stripe node calls fail in the same way
Creating payment intent is the last console log if I hard code the ephemeral key creation
rocky olive
all the stripe-node library should be doing at that point is try to make a REST call to our endpoint. If you replace that code with a generic REST call to somewhere else does that also hang and time out?
mighty path
Okay I went back to the tutorial I was using and it looks like they changed the implementation of the stripe-server file.
Does this makes sense why this implementation fixed it?
import Stripe from "stripe";
export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY as string, {
httpClient: Stripe.createFetchHttpClient(),
// https://github.com/stripe/stripe-node#configuration
apiVersion: "2025-04-30.basil",
appInfo: {
name: "expo-router-stripe",
},
});
rocky olive
Ah interesting, good catch. Glad that works now, I am not sure what issue non-lazy loading may have caused here and I am surprised that the try-catch wasn't throwing the expection that we would have thrown there. So it makes sense that that might help but I am surprised at the behavior you were seeing before
mighty path
Yeah makes sense thanks for your help