PATCH API 在 Google Cloud Run 实例上不起作用。

huangapple go评论151阅读模式
英文:

PATCH API don't work on Google Cloud Run instance

问题

我有一个托管GO OSB应用程序的云运行服务,通过grpc-gateway将其暴露为HTTP REST API,该应用程序使用Cloud SQL(MySQL)作为数据库。除了PATCH请求之外,所有的CRUD API都能正常响应。

它抛出了以下带有HTTP响应代码503的错误:

{
"textPayload": "The request failed because either the HTTP response was malformed or connection to the instance had an error.",
"insertId": "6141e984000c63529e7b7afd",
"httpRequest": {
"requestMethod": "PATCH",
"requestUrl": "https://--mr336-qv7hk7cx3a-uc.a.run.app/v2/service_instances/237e80fd-b22e-4df0-b9ed-23c91a4d7f51",
"requestSize": "1102",
"status": 503,
"responseSize": "976",
"userAgent": "PostmanRuntime/7.28.4",
"remoteIp": "",
"serverIp": "
",
"latency": "0.410343680s",
"protocol": "HTTP/1.1"
},
"resource": {
"type": "cloud_run_revision",
"labels": {
"location": "us-central1",
"revision_name": "--mr336-00001-hop",
"project_id": "--l-app-us-01",
"configuration_name": "--mr336",
"service_name": "--mr336"
}
},
"timestamp": "2021-09-15T12:39:32.811858Z",
"severity": "ERROR",
"labels": {
"instanceId": "00bf4bf02dff6d5f53cff1f1828cafbca265606a996eddff5cb44e3fff674efb77ca51eca7087fb8b8e7acba227b2a3e3e913bdfcc0a487640a2e028"
},
"logName": "projects//logs/run.googleapis.com%2Frequests",
"trace": "projects/
/traces/e29e5add9452d171e9eebd26817bb667",
"receiveTimestamp": "2021-09-15T12:39:32.817171397Z"
}

需要注意的几点:

在每个PATCH请求之后,我可以看到实例启动日志,即在上述日志之后,每次我都可以看到容器入口点(服务器)的启动日志(如冷启动)。

一旦服务器启动完成,它会再次在日志中抛出相同的错误。

需要注意的重要一点是,我也看不到我的应用程序的任何日志,这表明PATCH API请求未到达在云运行服务后面运行的容器实例。

此外,我的活动实例在冷启动后进入空闲状态,然后在最后一个请求命中后的1分钟内缩减为0,但这对其他API似乎没有问题。这是它应该工作的方式,但找不到PATCH的问题所在。

英文:

I have cloud run services hosting GO OSB application implementing gRpc but exposing the http REST api's via grpc-gateway which uses cloud sql (mysql) as a DB. All the CRUD API's are responding fine except the PATCH one.

It's throwing the below error with http response code 503:

{
  "textPayload": "The request failed because either the HTTP response was malformed or connection to the instance had an error.",
  "insertId": "6141e984000c63529e7b7afd",
  "httpRequest": {
    "requestMethod": "PATCH",
    "requestUrl": "https://********-********-mr336-qv7hk7cx3a-uc.a.run.app/v2/service_instances/237e80fd-b22e-4df0-b9ed-23c91a4d7f51",
    "requestSize": "1102",
    "status": 503,
    "responseSize": "976",
    "userAgent": "PostmanRuntime/7.28.4",
    "remoteIp": "********",
    "serverIp": "********",
    "latency": "0.410343680s",
    "protocol": "HTTP/1.1"
  },
  "resource": {
    "type": "cloud_run_revision",
    "labels": {
      "location": "us-central1",
      "revision_name": "********-********-mr336-00001-hop",
      "project_id": "********-********-l-app-us-01",
      "configuration_name": "********-********-mr336",
      "service_name": "********-********-mr336"
    }
  },
  "timestamp": "2021-09-15T12:39:32.811858Z",
  "severity": "ERROR",
  "labels": {
    "instanceId": "00bf4bf02dff6d5f53cff1f1828cafbca265606a996eddff5cb44e3fff674efb77ca51eca7087fb8b8e7acba227b2a3e3e913bdfcc0a487640a2e028"
  },
  "logName": "projects/********/logs/run.googleapis.com%2Frequests",
  "trace": "projects/********/traces/e29e5add9452d171e9eebd26817bb667",
  "receiveTimestamp": "2021-09-15T12:39:32.817171397Z"
}

Points to Note :

After every patch request I can see the instance start-up logs, i.e. after the above mentioned logs every time I can see the container entrypoint (server) startup logs (like cold-start).

As soon as server startup is complete, it again throws the same above error in logs.

Important point to note is that I also can't see any logs from my application which suggests PATCH api request is not reaching the container instances running behind the cloud run services.

Also my active instances after cold start goes to ideal and then scales down to 0 with in a 1 min. after the last request hit, but it doesn't seems to create issue for other APIs. This is how it is supposed to work but can't find any lead on what's the issue with PATCH.

答案1

得分: 1

这个问题已经修复了!

由于在同一个端口上处理多个协议,并且其中一个协议匹配器导致 PATCH API 出现问题,返回了服务器的空响应。所以,对匹配器进行了更改,问题得到解决。

根本原因分析(RCA):
Cmux HTTP1Fast 匹配器只匹配 HTTP 请求中的方法。
这个匹配器非常乐观:如果返回 true,并不意味着请求是一个有效的 HTTP 响应。
为了正确但较慢的 HTTP1 匹配器,使用了 "HTTP1",它会扫描整个请求,最多达到 4096 字节,但速度较慢。

英文:

This is fixed now !

Facing the due to handling of multiple protocols on the same port and one of the protocol matchers was causing the issue with PATCH API by returning Empty reply from server. So, done changes to the matchers and it worked.

RCA :
Cmux HTTP1Fast Matcher only matches the methods in the HTTP request.
This matcher is very optimistic: if it returns true, it does not mean that the request is a valid HTTP response.
A correct but slower HTTP1 matcher, used "HTTP1" instead which scan the whole request up-to 4096 bytes but its bit slow.

huangapple
  • 本文由 发表于 2021年9月15日 21:36:36
  • 转载请务必保留本文链接:https://go.coder-hub.com/69194259.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定