I used to get the errors object in AppSync response and a 5xx status code - if there was an error thrown from Lambda resolver (either a timeout error or a handled error I send as the first parameter in the lambda callback)
Eg.
`callback(errorMessage, …)
I can no longer see the errors object in AppSync – even though the Lambda resolver is throwing errors.
Is this a change in implementation or a bug?
I'm having to work around this by changing the response mapping template in AppSync resolver – to use $util.error based on a flag in the Lambda response.
While doing this – I'm able to get the errors object in AppSync response – but it’s still a 200 OK response.
Any way we can override this status code in AppSync?
Have you changed the version of mapping template that you are using from 2017-02-28 to 2018-05-29? The behavior on how invocation errors are handled changes between the two versions.
A snippet from the AppSync Developer Docs:
Previously, with 2017-02-28, in case of an invocation error, the response mapping template was evaluated and the result was placed automatically in the errors block of the GraphQL response.
With 2018-05-29, we can now choose what to do with the error, re-raise it, raise a different error, or append the error while return data.
You can find the AppSync Developer Docs that I am referencing here.
Currently you cannot customize the error status code in AWS AppSync.
The suggested approach is to use errorType in the error response. You can use $util.appendError or $util.error methods in your velocity mapping template to define the error type.
Related
I have implemented an AWS Lambda Authorizer in Java (type=REQUEST). I would like to invoke the lambda using a Function URL. I need to pass the following fields to my Lambda AuthorizerEvent:
headers
type (REQUEST)
methodArn
I am sending the HTTP GET message using Postman. The headers get mapped correctly to the event object. However, type and methodARN are shown as null in the CloudWatch logs and the Function URL returns a 502 Bad Gateway error:
Received AuthorizerEvent(type=null, authorizationToken=null, headers={...}, methodArn=null)
I've tried putting type and methodArn in query parameters, headers and body (even though REQUEST authorizers don't use the body, see here). I also can't find complete documentation outlining how HTTP parameters are mapped to the lambda request event parameters for Authorizer Function URLs.
Any help would be greatly appreciated!
Is there any way to get the response body in Azure Logic App even when we get 500 Internal Server Error?
I have made the Logic App in a way that I'm setting the response code to 500 on an issue, and I'm adding some error related information in the response body. I tried returning 504 Gateway timeout as well, in case of a timeout issue I could face, but I'm always receiving a null response body in case of non-200 response codes.
If we are not able to see the response body in case of an error by design, is there a better way to set and fetch error related information from the response object?
Yes you can get the response body in Azure Logic App by adding the response action. According to this Add a Response action section of the Microsoft document.
When you use the Request trigger to handle inbound requests, you can model the response and send the payload results back to the caller by using the built-in Response action.
Following steps would help you to get the response body.
In the Logic App Designer, under the step where you want to add a Response action, select New step.
The under Choose an action, in the search box, enter response as your filter, and select the Response action.
Now add any values that are required for the response message. For the Body, you can select the trigger body output from the dynamic content list.
I would suggest to read the Receive and respond to inbound HTTPS requests in Azure Logic Apps document for more information.
Alternatively you can also create alerts whenever HTTP 500 errors occur in your App and use Application Insights to view it using Azure Monitor. I would also suggest to read this Handle errors and exceptions in Azure Logic Apps Microsoft document for more information.
Have a simple Lambda POST integration with DynamoDB. Inserts one record into Dynamo upon execution. Works well when testing in AWS Lambda.
Response output is:
{
"isBase64Encoded": false,
"statusCode": 204,
"headers": {
"Content-Type": "application/json",
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Credentials": true
},
"body": "{}"
}
This response is programmatically defined as part of the Lambda response handling in accordance with the spec (afaict).
However, when run via a test in API Gateway, I receive a 502 Internal server error. Am using Lambda-Proxy integration as below:
Cloudwatch logs indicate:
{ ValidationException: Supplied AttributeValue is empty, must contain exactly one of the supported datatypes
at Request.extractError
with a limited use stacktrace (webpack has hashed the code pretty well). The above error would suggest DynamoDB is not receiving the payload correctly, or in a format it wants that honours required attributes. However, I have taken the same JSON used for the (successful) tests (tweaking the IDs to be unique between runs) from lambda, and believe my request header (Content-Type: application/json) is sensible.
Any thoughts / help on narrowing down the issue? I can post more info as requested if it helps.
Ok, solved this by logging all output (and inspecting in CloudWatch), in particular the event object. When running in a Lambda Test mode, the ID and other POST attributes were passed in the root of the event object. However, when using lambda-proxy mode, the integration remaps the event object hierarchy, and POST attributes are JSON stringified into the body attribute.
Just a quirk that makes sense once you understand what it's doing. That said, it's odd that the same payload fails when testing Lambda & API Gateway in turn.
I have a (Python) Lambda function that I'm calling via AWS API Gateway (not using "Lambda Proxy integration").
The Lambda accepts a JSON payload, and if all goes well returns a JSON response.
In terms of monitoring the Lambda, I can see the following in CloudWatch:
invocations
duration
throttles
errors
The Lambda can fail in a number of ways, and in each of these cases a JSON error object is returned as the response.
I would like to add the ability to view metrics of these error conditions in CloudWatch, but reading the documentation on Cloudwatch alerts and alarms, it is not clear to me how to do this. Any ideas?
How to add the unhandled exceptions accross the applications in response body in WEB API. If there is no exceptions a success message needs to be sent to the response body for all the responses....Need help on achieving this.
You need two things. For handling the exceptions, you need to set the IncludeDetailErrorPolicy in the HttpConfiguration object,
You can configure the error policy preferences as part of the configuration object (HttpConfiguration) in the IncludeErrorDetailPolicy property. This is just an enum that instructs Web API about how to deal with exceptions.
The possible values for this enum are,
Default: It’s uses the customErrors configuration settings if you are using ASP.NET as host or LocalOnly for self-host.
LocalOnly: Only includes error details for local requests
Always: Always includes error details
Never: Never includes error details
When an exception happens, Web API will check the value on this setting for including details about the exception in the response message or not. For example, if Always is enabled, Web API will serialize the exception details as part of the message that you get as response.
The success message does not make much sense as you already have the response status code. A status code equals to OK means that everything went ok. If you still want to add an additional message, use a HttpMessageHandler that checks for the response status code. If the status code is OK, add the message. However, the response body has been set already at that point so you will not able to modify it. You might able to add a message as a header.