Fork me on GitHub

In aws-api, the docs for client (and invoke as well) say that it takes the option:

:retriable? - optional, fn of http-response (see
It seems that the http-reponse it's referring to should be: In practice it seems that the retriable? fn actually takes the fully parsed api client response, not the http response. Is this a typo on the docstring? Or is this just an implementation detail, because the library's defaults only check for a couple anomalies which would be on an http response map as well as the final parsed response? Should retriable? implementations assume they are receiving an http response map (linked above?). I'm asking because I've been thinking about using the retry/backoff mechanism for non-anomalous responses/application level polling. For example, calling ec2's :DescribeInstances to wait for a particular status change to complete. Is this a bad idea, due to the above (or any other reason)?


thinking out loud, depending on what happens after status change, started wondering if you could use (used to be called cloudwatch event rules), to listen for status changes:


Yeah I had considered something like that, but if i want just a notification on my dev machine roughly when an instance is ready, it doesn't really prevent having to either poll something or set up a lambda or server or something. This actually works pretty good and doesn't require any more code, assuming retriable? can be relied on to always be passed the actual api result as it is now.

{:op :DescribeInstances
   :request {;;...
   :retriable? not-running?
   :backoff (fn [x]
                (zero? x) 60000
                (< x 20)  5000))}

👍 1