How do I record http method and response code from lambda

[calidan-x]

"The other difference between instrumenting Lambda functions and web applications is that the segment that Lambda creates and sends to X-Ray cannot be modified by your function code. You can create subsegments and record annotations and metadata on them, but you can't add annotations and metadata to the parent segment." --- from AWS doc

I found whatever statusSode return from lambda, the tracing information always wrote 200 and mark as correct request. And the request path and method are all missing. what should I do to fix it?

[calidan-x]

Using ALB -> Lambda

[calidan-x]

if a subsegment fail, is it possible to mark the the main segment fail?

[srprash]

Hi @calidan-x The Lambda service opens a segment on your behalf when the function is invoked. This segment is immutable as you mentioned in this issue description.

Even though you return a non-200 status code from your lambda function, the lambda service reports 200 on X-Ray trace. This is because the Lambda service report 200 since the function was invoked successfully and a response was received.

If you were to throw an error within the function, then you would see that lambda function segment will report this error.

[calidan-x]

I understand it completely. But if xray cannot tracing the response code from lambda, it make no sense for tracing error.

Will Amazon improve it in feature?

Right now I am working on a nodejs backend framework https://summerjs.dev/ the framework can build all code into a single index.js (runs in lambda/ecs), I wish to construct a full serverless architecture, use lambdas as backend restful api providers and integrates with Xray. Xray can trace lambda response code is so important.

[srprash]

I understand the ask and the value of it. This is something where X-Ray would need to work with AWS Lambda to be able to get the actual response code from the lambda function. So I cannot provide any ETA for this enhancement but X-Ray team will provide an update here so please stay tuned.

[calidan-x]

Thank you!

[jvit]

any progress on that?

it makes X-Ray on Lambda quite unusable. When I open traces, everything is green eventhough some of them might have failed. As calidan said, it makes no sense to use this for tracing errors.

[andres-sinapsis]

I also think this too important. Without the capacity to reading the statusCode from lambda there aren't much sense to use x-ray for debugging process. This even worst when you use ApiGateway in Http Ingration where is not possible to use x-ray, so there isn't way to realize then a lambda returns 4xx or 5xx to ApiGateway.

[willarmiros]

Thanks for the feedback, this will require changes with our APIGW and/or Lambda integrations so is not completely under X-Ray's control, however we have noted the request to them and will update this issue if there is anything new.

[wilsonrm]

Hi Guys, yes it would make the Lambda Xray tracing much more usable, would be able to provide any update on this please?

[blytheaw]

I +1 this. We use API Gateway v2 (HTTP API) exclusively which doesn't have active X-Ray tracing and therefore we have no indication that requests failed because the first segment shows successful due to the 200 response code from lambda, regardless of what the response's status code shows.

[mward-LT]

To add to this, my use case is such that I have a Lambda function that processes messages in batches. And within the message processing, this translates in the code to a for loop to go through the records. If I encounter a message which is malformed (a problem with the data provider, not my data processor), I do not want the entire function to fail. Instead, I just "continue" to the next record, but I would like to ultimately distinguish the return code of the entire function as "total success 200" versus a custom code that indicates to me, "succeeded, but with malformed records."

In the meantime, what I've done to accomplish my case, is in the case of such a record being encountered, I annotate the entire function as "malformed_data_detected = true", which allows me to still find these later through filter expressions. I'll be fair and say that in my case this "works," but I will also say that it was an unnatural solution to me which took me down a lot of winding paths (I ended up opening a support case which led me here asking to why I couldn't change the status code).