Clojurians Log v2
aws
I'm glad to be seeing some :thumbsup: 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.
Planning to test this later today and give some feedback.
Thanks @christian.gonzalez
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.
that seems like the right thing to do
the data is already exposed
and aws/invoke has a uniform interface across all services
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.
If invoke was exposed on the Client protocol, that'd be easy to do.
Has anyone had any success with JVM/CLJ + Lambda + Provisioned Currency?
@kenny you're in solution space, but I only deal in problem space 🙂
what's the actual problem without presuming a solution?
is it inconvenient to reach into grab the x-amzn-requestid header?
(inconvenience is legit IMHO)
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.
thanks this is more helpful
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.
> amazon is not returning values that pass their spec ^ very interested in this
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.
in what way was the token invalid?
some pagination tokens expire, for example
The entire message was this "Invalid NextToken provided."
There's no way this expired. The code executes sequentially in a very short period of time.
Well, if it did expire, the token would have an expiry of less than 10s.
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.
You had other requests successful with the continuation tokens?
Yes. This code executes often so it was very strange that one failed like this.
weird
Very. The next-tokens are a bit strange with this api too. They look like uuids.