#3hx_error

1 messages · Page 1 of 1 (latest)

uncut hemlockBOT
#

👋 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/1415699623804407838

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

oblique jay
#

If you need anything else - let me know 👍

wheat scroll
#

Hi, can you share the exact error you're seeing? Can you share the request id when you attempted to make that GET call?

oblique jay
#

It's not an error in the API as such, the API works just fine (I get a 200 OK from the api response).

It's the Stripe.net c# package that has the problem.

#

My logs don't store the request ID's

#

Becuse the duration of this code is 99,999 months (was my workaround for indefinite being deprecated)

#

The stripe.net package I guess is adding the 99,999 to DateTime.Now which results in c# throwing an System.ArgumentOutOfRangeException

#

I guess the stripe.net package is doing this check to ensure that the coupon is still valid

#

It makes sense now that I come to think of it.

#

But it's still an unhandled exception in the stripe.net package because you should never be allowed to exceed the DateTime.Max object

uncut hemlockBOT
wheat scroll
#

I do not have a .net environment running but I'm trying this using Node to see if I get an error.

oblique jay
#

I'm using the dashboard to create and manage the coupons

mortal wagon
#

Hey there stepping in for pgskc as they need to step away, but i infer that forever is not an option here due to the removal for amount_off coupons

#

I can report this bug internally, since valid params shouldn't cause event parsing errors, but in the meantime I would suggest using a smaller duration in months

oblique jay
#

👍

mortal wagon
#

Even 1200 months, 100 years from now, would be well within the max range

oblique jay
#

I've fixed it by using a percentage discount forever instead of an amount off

#

👍

#

Was a weird one I thought i'd future proof by a few thousand years 🤣

mortal wagon
#

There are good reasons to use amount vs percent, so dont let this deter you from using amount if thats what you want

#

Thanks for reporting, its certainly an unexpected outcome. Probably that duration should be limited to more reasonable values.

oblique jay
#

For what I was needing, % off is all good mate thanks

#

Yeah for sure. It took me a few hours to find it, but some other people might not be so lucky

mortal wagon
#

Yep, will see what we can do to address it. Not sure if there's a longer datetime type though 🤷

oblique jay
#

Nah there isn't, this is a .Net thing. Their MaxValue cannot be exceeded

#

Unless the Stripe.net code base could be altered to handle the exception

#

If it's out of range in the upper end then it's still a valid code

#

I could write a fix for it if you guys need. Let me know 🙂

mortal wagon
#

Can you share an example checkout session id (cs_test_123) that this coupon was applied to? Helps to have a concrete example when reporting the issue internally.

#

Or one of the webhook event ids (evt_123) that failed deserialization

#

Oh wait, it was a retrieval of the session, not a webhook

#

so yea, just the session id then

oblique jay
#

cs_live_b1prE0a5QHafexxyEOnVgZEiChpwB9IfwBz8Kn49BDd4axAMzAcD4igSr0

#

I've since deleted the code that was used

oblique jay
# oblique jay

But this is how it was set up, instead with SUYC as the customer-facing