Fork me on GitHub
#aws
<
2020-05-06
>
kenny15:05:54

aws-api doesn't seem to be mapping a 429 -> busy anomaly. Bug?

{:Reason "ReservedFunctionConcurrentInvocationLimitExceeded",
 :Type "User",
 :message "Rate Exceeded.",
 :cognitect.anomalies/category :cognitect.anomalies/incorrect}

(meta *1)
=>
{:http-request  {:request-method :post,
                 :scheme         :https,
                 :server-port    443,
                 :uri            "",
                 :headers        {},
                 :body           "",
                 :server-name    ""},
 :http-response {:status  429,
                 :headers {"connection"       "keep-alive",
                           "x-amzn-requestid" "",
                           "x-amzn-errortype" "TooManyRequestsException",
                           "content-length"   "103",
                           "date"             "Wed, 06 May 2020 15:16:56 GMT",
                           "content-type"     "application/json"},
                 :body    ""}}

jaihindhreddy15:05:17

Busy would be 503 wouldn't it? 429 is the service refusing your request rate, not being unable to serve it cuz they're busy. Of course, what we might choose to do when we counter either might be the same, but they're two different things, aren't they?

kenny15:05:04

Perhaps. Either way, incorrect is not the correct category. This request should be marked as a category that is retriable.

kenny16:05:41

From an end user perspective, I think 429 = 503.

ghadi16:05:37

we only map whatever is in the AWS provided descriptors

ghadi16:05:53

which we know isn't comprehensive w.r.t. errors

ghadi16:05:34

we're working on some functionality that would, among other things, potentially make it easier to fill in gaps where the service descriptors are insufficient

kenny16:05:28

Oh, didn't realize this was how it worked. Why not map http request statuses?

kenny21:05:21

@dchelimsky I think 429 = busy. Thoughts?

dchelimsky21:05:46

429 is about rate limiting, which could be happening based on e.g. a service contract (you're allowed n requests) even if the server could handle them.

kenny21:05:32

I realize that but the end user effect is identical.

kenny21:05:16

i.e., both use the Retry-After header and represent temporary conditions. I think they should be treated the same.

jaihindhreddy06:05:00

In a multi-tenant system for example, you might want to flow rate-limiting upstream to the tenants, whereas 503 is almost always reacted to with a retry with backoff.

kenny14:05:47

I'm now very much in agreement with @dchelimsky. I have a hard time qualifying with an "almost always" and would instead say it is very use case dependent. I see both sides of the coin now and agree that there is no default that can possibly satisfy every use case. Leaving the current defaults as is is safest. Allowing this to be configurable is really the only solution 🙂

dchelimsky21:05:04

That's your preference, but it might not be everybody's. As Ghadi mentioned, we're working on something that will allow you to post-process errors.

kenny21:05:41

Fair enough. Curious what situation you're thinking in which you'd handle them differently?

dchelimsky21:05:53

If you're actually being rate-limited.

dchelimsky22:05:20

Retry might not be the right answer in that case.

kenny22:05:51

Couldn't you make the same case for a server being "busy"?

dchelimsky22:05:12

Sure, but "making a case" is part of the point I

dchelimsky22:05:12

These things are up for interpretation, and are implemented and handled wildly differently not only across the entire internet, but even across AWS services.

dchelimsky22:05:36

So, we're going to give you control over this, and probably not change any of the decisions we already made as defaults.

dchelimsky22:05:26

Consider github's choice to return a 404 when you're not authorized to see a repo.

dchelimsky22:05:47

They'll justify it as security. Fine. But choices like that make status codes useless.

gerred01:05:46

well, from your perspective as the requester, maybe that one's actually true? 😉

gerred01:05:02

purely trolling here