Clojurians Log v2

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://lambda.us-west-2.amazonaws.com|lambda.us-west-2.amazonaws.com>"},
 :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    ""}}

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?

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

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

we only map whatever is in the AWS provided descriptors

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

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

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

We map some statuses that map clearly to anomaly categories: https://github.com/cognitect-labs/aws-api/blob/5e1a88a1f5bba49a2a235336f8f59b81ca89b944/src/cognitect/aws/protocols/common.clj#L10-L14

@dchelimsky I think 429 = busy. Thoughts?

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.

I realize that but the end user effect is identical.

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

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.

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

If you're actually being rate-limited.

Retry might not be the right answer in that case.

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

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

'm making

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

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

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

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