This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # aws (38)
- # aws-lambda (21)
- # babashka (45)
- # beginners (95)
- # boot (1)
- # calva (32)
- # cider (29)
- # clara (7)
- # clj-kondo (41)
- # cljs-dev (29)
- # clojure (145)
- # clojure-europe (6)
- # clojure-italy (12)
- # clojure-nl (4)
- # clojure-spec (39)
- # clojure-uk (45)
- # clojurescript (171)
- # copenhagen-clojurians (4)
- # crux (5)
- # cursive (14)
- # datomic (48)
- # docker (6)
- # figwheel-main (2)
- # fulcro (54)
- # jackdaw (1)
- # jobs (1)
- # kaocha (3)
- # leiningen (7)
- # luminus (6)
- # malli (2)
- # off-topic (52)
- # pathom (8)
- # quil (20)
- # re-frame (14)
- # reagent (1)
- # reitit (2)
- # remote-jobs (1)
- # shadow-cljs (39)
- # tools-deps (4)
- # vim (12)
I'm glad to be seeing some 👍 s, but I don't know if that's because you like the idea or you've checked it out. If you've checked it out and it's working well for you, please let me know (either say so or give me a ✅ on the message above). Thanks!
I’m happy to test, I guess the main thing is if my code creates two different clients (e.g. one Route53 and one Cloudwatch) and things keep working, right? I don’t have much instrumentation in this code about threads so I wouldn’t know where to look.
Any explicit feedback is helpful at this point, so yes, please! Don't worry about instrumentation.
Is there some way to add middleware to a client? If a request fails, I'd like to include the
"x-amzn-requestid" header in the resulting anomaly.
the metadata of the response should have a key
:http-response with all the relevant details @kenny
Yes. I'd like to always attach the request-id header if the request resulted in an anomaly.
The only obvious way to do that right now is to write my own invoke function and use that everywhere.
It'd just be nice to have a way to ensure the request-id is always included. Developers may forget to use our own invoke function instead of the built-in one.
Haha. The problem is ensuring the amzn-request-id is always included in the result if an anomaly occurred. Writing our own
invoke function works but has the fatal flaw of humans being forgetful. There's no way to ensure that our
invoke function is always used instead of the built-in
invoke function. This is, of course, a classic case of "don't do that". While that's fair in some cases, I don't think that's a great solution here. It seems far better to have a solution that will ensure all of our code follows the conventions mandated.
The arises because we are hitting some cases where amazon is not returning values that pass their spec. Their support team requires the request-id. We like to log as much information as we possibly can to make these issues easier to figure out retractively. Therefore it seems to make sense to always include a request-id if an anomaly occurs.
do all errors have a amzn reqid? do all requests have a amzn reqid? are there other headers that come back that are of general use?
In this particular case, I have no way to reproduce the issue we were seeing because it doesn't seem possible. If the request-id was logged amazon could have debugged further.
Those are all great questions and I don't know the answer. I did some brief googling a bit ago and couldn't find anything that ensured amazon always included the request-id in the response headers. The function I would write would include the
"x-amzn-requestid" in the anomaly if it existed in the header map.
The case we hit was a pagination token was returned that was not valid. We didn't log the pagination token so we couldn't send it to amazon. We did log the anomaly which has basically no useful info besides saying the NextToken was invalid. If the anomaly had the request-id, Amazon said they could dig in further.
There's no way this expired. The code executes sequentially in a very short period of time.
Anyway, we are now logging the pagination token to hopefully debug further. I would've liked to had a better answer from amazon by providing the request-id.