#ianvs_error
delicate prismBOT
👋 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/1222972752198107167
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
faint knotBOT
warm isle
Do you have a site where I could see it happening? Can you elaborate on "it seems to happen when loading the page and very quickly using it"
mellow hawk
We use storybook tests, which render the page in a headless browser using playwright, and then close it out for the next test. I don't get any errors when loading the actual page
I'm trying out a small sleep before we start interacting with the page in the test, to see if that helps.
Nope, doesn't seem to help.
warm isle
And this is only happening in your storybook tests, right? It's not something you can reproduce outside of that?
mellow hawk
So far. But our site doesn't get a ton of traffic on the billing pages, so it's hard to say for sure. Do you know if something changed in the last few days that could have caused this? It was working fine up until just recently
warm isle
Let me check in with some other folks and see if they've seen this before
delicate prismBOT
untold moss
We're not aware of anything that would have changed something like it, it seems more likely related to the way Storybook renders your components in the tests.
We don't recommend doing UI tests against Elements like this, though
Preferring instead that the Elements bits are mocked based on config and outcomes
Can you share an example test for context?
mellow hawk
Are there any resources you can recommend that explain how this should be done?
I had a really hard time finding any info about testing elements
untold moss
Curious how you're using this / what you're trying to verify
While it may be possible, our current guidance is to not do this:
Frontend interfaces, like Stripe Checkout or the Payment Element, have security measures in place that prevent automated testing, and Stripe APIs are rate limited.
https://docs.stripe.com/automated-testing
mellow hawk
We don't do anything terribly fancy in our SB tests, mostly just ensure that the pages render the way we are expecting. Here's an example of our checkout form, we render it and make sure that we see the parts on the right that aren't from stripe
We use e2e tests to verify that we can actually use the form to sign up, etc.
untold moss
Right, so for those flows for example you would want to avoid trying to put in card details etc, preferring to mock those results as successful or failed payments
untold moss
Yep, understood, just mentioning for the e2e tests you described
untold moss
For these renders tests, you could similarly drop out the payment element conditionally on the test env
if the test isn't actually reaching into it, it would not affect your plan display panel
I can't really say what might be happening that produces the error up top without being able to inspect a reproduction
mellow hawk
We're mixing up tests I think. My frontend tests don't fill out the form. The e2e tests actually sign up a user in our dev stripe account
untold moss
And I'm not familiar enough with Storybook's patterns to guess what might trigger that
mellow hawk
I can try to mock out loadStripe from @stripe/stripe-js I suppose?
But I'm surprised that the JS can't handle loading in a page in this environment
untold moss
Do you have a callstack for where that error gets thrown?
mellow hawk
yeah one sec
untold moss
eg, if storybook uses any kind of server side rendering, stripe.js won't work there (perhaps "sometimes" explaining the intermittent behaviour?)
mellow hawk
"TypeError: Cannot read properties of undefined (reading 'dispatch')\n at elementUnmounted (https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:668426)\n at https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:675382\n at n (https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:65193)\n at Generator._invoke (https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:64946)\n at Generator.next (https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:65375)\n at a (https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:70686)\n at o (https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:70870)\n at https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:70948\n at new Promise (<anonymous>)\n at e.<anonymous> (https://js.stripe.com/v3/fingerprinted/js/controller-d3ccb6cf4771c2700fb94b92ad4b67de.js:1:70829)"
No server rendering, it's all in the client
let me see if I can see it in dev as well, one sec
hmm, no so far I can't reproduce outside of storybook. I'll work on finding a way to avoid calling loadStripe() in my tests
But FWIW I didn't change anything else in the last few days when this started to fail, so I think something in stripe must have changed.