【问题标题】:AWS Amplify returns generic Network Error on any Lambda failureAWS Amplify 在任何 Lambda 故障时返回一般网络错误
【发布时间】:2019-01-31 05:59:53
【问题描述】:

我正在构建一个应用程序,该应用程序通过 Web (React) 前端上使用的 AWS Amplify 与 AWS (API Gateway/Lambda) 上的无服务器 API 连接。

当请求成功时,一切正常(当然,我想)。没有CORS问题或任何东西。但是,如果我尝试返回“失败”响应,我的前端不会收到该响应。它收到一个通用的Network Error,没有关于发生了什么的信息,控制台记录了一个失败。

我认为代码会更有意义。我使用这样的代码向 API 请求(在其他地方配置放大):

import { API } from 'aws-amplify';
...
API.get('apiName', path, options)
  .then(response => {
     // Whatever
  })
  .catch(err => {
     // Whatever
  })

在 Lambda 中,我返回(并且 Cloudwatch 验证了这一点,因为我在运行 callback(null, responseObject) 之前就记录了)一个完整的响应对象,如下所示:

{
    "statusCode": 200,
    "headers": {
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Credentials": true
    },
    "body": "{ /* whatever */ }"
}

或者这个:

{
    "statusCode": 500,
    "headers": {
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Credentials": true
    },
    "body": "{ /* error here */ }"
}

200 的情况下,响应完美地到达了我的前端(在.then 函数中显示为response)。在500(或一般错误)情况下,.catch 被称为并且err 对象不是我放在响应正文中的,而是没有相关信息(或状态码)的通用Network Error

Error: Network Error
    at createError (createError.js:16)
    at XMLHttpRequest.handleError (xhr.js:87)

为了澄清,只需 statusCode 从 200 更改为 400 都意味着请求在前端被捕获(很好),并且错误没有我返回的任何信息Lambda(坏)。

控制台也会记录错误:

DELETE https://abcdefg.execute-api.us-west-2.amazonaws.com/development/my-endpoint 403 ()

Failed to load https://abcdefg.execute-api.us-west-2.amazonaws.com/development/my-endpoint: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. The response had HTTP status code 403.

它还会记录与我没有意义的 CORS 失败相关的内容,因为我遵循与成功案例相同的exact模式,只是使用了更高的statusCode

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://abcdefg.execute-api.us-west-2.amazonaws.com/development/my-endpoint with MIME type application/json.
XHR failed loading: DELETE "https://abcdefg.execute-api.us-west-2.amazonaws.com/development/my-endpoint".

知道这里发生了什么吗?无法访问前端真正的信息错误真的很令人沮丧。如果有任何其他信息有助于解决此问题,请告诉我。

编辑 -- 根据@Michael 下面的反馈,我检查了我的应用程序使用的是 lambda 还是 lambda-proxy,事实上,它使用的是 lambda-proxy,应该 not 据我了解,不会产生这种行为。

这是我的 serverless.yml 文件中的一些代码,

functions:
  projectsGetAll:
    handler: handlers/projects/getAll.handler
    events:
      - http:
          path: projects
          method: get
          cors: true
          authorizer: aws_iam

这是来自 AWS API Gateway 的针对这些端点之一的屏幕截图(端点被涂白):

我想确认这是 lambda-proxy 的意外行为。是不是有些设置搞砸了?

【问题讨论】:

    标签: reactjs amazon-web-services aws-lambda serverless-framework aws-amplify


    【解决方案1】:

    如果您正在使用 API Gateway 并遇到此问题,请确保更新 API Gateway 的“网关响应”默认 5XX 和默认 4XX 标头以包含正确的响应标头(和/或消息)——否则@错误响应时不会发送 987654321@,您的浏览器将抛出“网络错误”。

    例如,将默认 5XX 和 4XX 的响应标头设置为:

    Response header: Access-Control-Allow-Origin
    Value: '*'
    

    更新这些默认标头值解决了我的问题,现在正在解决正确的错误消息。

    【讨论】:

      【解决方案2】:

      想通了!返回的错误对象(通用500NetworkError 包含 我构造的错误,在response 键下)。

      所以如果我记录error.response,我会得到完全构造的错误对象,它有自己的消息和statusCode,即使错误对象本身有500codeError: Network Error 的消息,并且错误捕获过程似乎在控制台中抛出了不准确的错误日志(CORB 内容)。

      很奇怪。不确定这是否是预期的 Lambda 行为,或者 Amplify 的某些行为,或者我做错了什么,但如果其他人遇到这个问题,我希望这会有所帮助!

      编辑 - 显然这是我在文档中遗漏的预期放大行为。

      但我发现了另一个似乎是错误的问题。此响应键仅在我在请求选项中指定 headers 时显示。换句话说,这个请求返回一个带有response 键的error

      API.get('my-api', '/path')
      

      但是这个没有key就返回错误:

      API.get('my-api', '/path', { headers: { 'Content-Type': 'application/json' } })
      

      很奇怪,但对我来说是真的。甚至 other 选项都很好,但 headers 选项似乎把事情搞砸了(并且仅用于错误响应)。

      【讨论】:

      • 感谢您跟进此@Sasha - 我目前遇到同样的问题,即使没有标题也没有得到密钥错误 - 您是否对这段代码有任何问题必须为此打补丁吗?
      【解决方案3】:

      这最终取决于您如何配置 API 网关,例如Lambda 代理等。如果您不使用 Lambda 代理设置,则需要在 API Gateway 中映射这些错误响应/代码,请参阅此处的大量帖子: https://aws.amazon.com/blogs/compute/error-handling-patterns-in-amazon-api-gateway-and-aws-lambda/

      如果您使用的是 Lambda 代理,您只会从 Lambda 作为特定类型的代理响应返回:https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy-for-lambda.html

      【讨论】:

      • 在上面添加了编辑——我配置了 lambda-proxy,所以不幸的是,这似乎不是它
      猜你喜欢
      • 2018-02-14
      • 1970-01-01
      • 1970-01-01
      • 2020-11-15
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-06-17
      相关资源
      最近更新 更多