grpc-transcode的proto文件的配置变化对于inflight请求的Response是否有不一致问题？

[listen-lavender]

curl http://127.0.0.1:9180/apisix/admin/protos/1 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "content" : "syntax = \"proto3\";
    package helloworld;
    service Greeter {
        rpc SayHello (HelloRequest) returns (HelloReply) {}
    }
    message HelloRequest {
        string name = 1;
    }
    message HelloReply {
        string message = 1;
        string name = 2;
        string abc = 3;
    }"
}'

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/grpctest",
    "plugins": {
        "grpc-transcode": {
         "proto_id": "1",
         "service": "helloworld.Greeter",
         "method": "SayHello"
        }
    },
    "upstream": {
        "scheme": "grpc",
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:50051": 1
        }
    }
}'

用户发送请求curl -i http://127.0.0.1:9080/grpctest?name=world，apisix已经收到http request，并转发到grpc upstream，还没有拿到grpc response，这个时候变更以下配置

curl http://127.0.0.1:9180/apisix/admin/protos/2 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "content" : "syntax = \"proto3\";
    package helloworld;
    service Greeter {
        rpc SayHello (HelloRequest) returns (HelloReply) {}
    }
    message HelloRequest {
        string name = 1;
    }
    message HelloReply {
        string message = 1;
        string hk = 2;
    }"
}'

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/grpctest",
    "plugins": {
        "grpc-transcode": {
         "proto_id": "2",
         "service": "helloworld.Greeter",
         "method": "SayHello"
        }
    },
    "upstream": {
        "scheme": "grpc",
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:50051": 1
        }
    }
}'

变更完配置之后，拿到grpc Response，是按照proto_id=1解析还是按照proto_id=2解析呢？

[dosubot[bot]]

Hi @listen-lavender! I'm Dosu and I’m helping the apisix team.

对于 grpc-transcode 插件，proto 文件的解析是在请求进入 APISIX 时（access 阶段）根据当时的 proto_id 加载并缓存到本次请求的上下文中。即使在请求转发到 gRPC upstream 后、响应还未返回时你修改了 proto 配置和 route 的 proto_id，inflight 的请求依然会用最初收到请求时加载的 proto 解析 response，不会受到新配置影响。只有新进入的请求才会用到新的 proto 配置。

换句话说，你描述的 inflight 请求，最终解析 gRPC response 时会用 proto_id=1 的定义，不会用 proto_id=2 的定义。这个行为在插件源码中有明确体现，proto 对象在 access 阶段就被锁定在 ctx.proto_obj，后续 body_filter 阶段直接复用，不会重新加载 参考。

所以不会出现 inflight 请求因 proto 配置变更导致 response 解析不一致的问题。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}