Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client: valid json response decode error: "{" expected: unexpected byte 34 '"' #1315

Closed
veqryn opened this issue Sep 14, 2024 · 5 comments
Closed
Labels
bug Something isn't working

Comments

@veqryn
Copy link

veqryn commented Sep 14, 2024

What version of ogen are you using?

v1.4.1

Can this issue be reproduced with the latest version?

Yes

What did you do?

Generated a golang client, used it, received an error, and ogen wasn't able to decode the error.

Here is the openapi spec that generated ogen's client:
https://github.com/veqryn/awesome-go-api/blob/c737ba1703d2ca30be0d898b17717eca8c70565f/protobufv3/openapiv3/gen/openapi.yaml#L248-L259

Here is the client that uses the generated code:
https://github.com/veqryn/awesome-go-api/blob/c737ba1703d2ca30be0d898b17717eca8c70565f/protobufv3/openapiv3/ogen/main.go#L48-L49

When I curl the server, the response looks like this:

$ curl -vv -k -L localhost:8080/error
* Host localhost:8080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8080...
* Connected to localhost (::1) port 8080
> GET /error HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 400 Bad Request
< Content-Type: application/json
< Date: Sat, 14 Sep 2024 06:05:49 GMT
< Content-Length: 306
<
* Connection #0 to host localhost left intact
{"code":3, "message":"This is an example error", "details":[{"@type":"type.googleapis.com/google.protobuf.Any", "value":{"@type":"type.googleapis.com/google.protobuf.DoubleValue", "value":224.92}}, {"@type":"type.googleapis.com/google.rpc.LocalizedMessage", "locale":"en-US", "message":"Fix your widget"}]}

Ogen seems to be unable to decode that response body into the rpcStatus object details.

What did you expect to see?

No decode error.

What did you see instead?

(*errors.wrapError)(0x140000b8b80)(decode response: default (code 400): decode application/json: decode RpcStatus: callback: decode field "details": callback: decode ProtobufAny: callback: decode field "locale": decode ProtobufAnyAdditionalItem: "{" expected: unexpected byte 34 '"' at 267)
@veqryn veqryn added the bug Something isn't working label Sep 14, 2024
@tdakkota
Copy link
Member

protobufAny is defined as:

{
  "type": "object",
  "properties": {
    "@type": {
      "type": "string"
    }
  },
  "additionalProperties": {
    "type": "object" // <-- all properties should be objects except @type
  }
}

and input is:

{
  "@type": "type.googleapis.com/google.rpc.LocalizedMessage",
  "locale": "en-US", // <- string
  "message": "Fix your widget"
}

It seems for me that decoder works as intended. Error message might be more clear, I guess.

@veqryn
Copy link
Author

veqryn commented Sep 15, 2024

Hm...

The yaml was created by the gRPC Gateway, which only supports OpenAPI v2:

  protobufAny:
    type: object
    properties:
      '@type':
        type: string
    additionalProperties: {}

I upgraded it to v3 using swagger-codegen, which turned it into this:

    protobufAny:
      type: object
      properties:
        '@type':
          type: string
      additionalProperties:
        type: object

So I'm not an expert in OpenAPI.

I am guessing that instead of additionalProperties: {} in the v2 yaml, it should be additionalProperties: true, is that correct?
Or is it a problem with the v2 -> v3 translation?

@tdakkota
Copy link
Member

In OpenAPI 3, additionalProperties: {} is effectively the same as additionalProperties: true. It seems there is bug in swagger-codegen, it should not add type: object.

@veqryn
Copy link
Author

veqryn commented Sep 16, 2024

@veqryn veqryn closed this as completed Sep 16, 2024
@veqryn
Copy link
Author

veqryn commented Sep 16, 2024

@tdakkota thx. I've got a workaround/hack for this to generate the correct v3, but now I'm running into this issue/feature-request #1313

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants