#sukatoa-error

1 messages · Page 1 of 1 (latest)

coarse turret
#

👋 happy to help

#

could you please provide a request id?

serene hull
#

hold on, looks like we don't have that one on our logs

#

any req_*? or you want specific one?

#

this is the latest one - req_Am1DlKmxMG4W6N

coarse turret
#

one that is resulting in 429

serene hull
#

aahhh no, we haven't encountered that one yet. So I am asking ahead to make it fool-proof in future when the app in prod encounters that one, our threads should be able to handle that

#

our thread workers were handling the returned Subscription objects straight forward, but doesn't know what to do if it gets 429, and doesn't even know where to find that 429 yet.

#

I'm initially thinking of making a small program to burst the test server but it's unethical and would take more time for me. So I instead reach out here making sure where to get that 429 so we can program it ahead. Not sure if you have proprietary tools for us to use to simulate that scenario

coarse turret
#

I'm sorry but I'm not following

serene hull
#

I see. let's take it this way

#

assuming we have multiple threads doing read/write/updates to stripe server

#

stripe detected that we reach the maximum allowed write/read transactions per second. stripe throws status 429 (per the article, but we don't know yet how to determine)

#

so programmatically (ex), when the thread executes subscriptionObject.getSubscription(id) and this detected by stripe that we reached the maximum limit. Are we still able to receive a subscription object? If yes, does the 429 value can be found on that subscription object via subscription.getStatus()? - Java

coarse turret
#

oh now I see what you mean

#

unfortunately if you get a 429 you will get an error and not an object (whether it's subscription or anything else)

serene hull
#

gotcha! thanks much