Deserialization issue when getting self service flow about sdk HOT 7 CLOSED

That or generate their own client using the openapi-generator and the spec at: https://github.com/ory/kratos/blob/master/spec/openapi.json

The 0.7 release is pretty close though: https://github.com/ory/kratos/milestone/9

from sdk.

Dupe of #74

from sdk.

Shit, I made a long post that explained the issue but apparently I closed the wrong window. Anyways, the gist of it is that polymorphism with simple types is simply extremely buggy in basically all the generators except for Golang (because I fixed it there) and TypeScript. Apparently, the generator expects polymorphism to always be a JSON object 🤷

So what I did was to remove the typing from the value (which means it can be any type) and re-generated the clients. Could you please check if this works in Java (I have no Java experience...). The generated code with the changes can be found here: https://github.com/ory/sdk/tree/openapi-fixy/clients/kratos/java

Thanks!

from sdk.

@aeneasr, thanks for the quick reply. I just quickly tested your fix and the login and registration flow responses are now deserialized correctly! Hopefully, this fix also solves the issues with the clients in other languages. Could you maybe point out what you exactly changed since db67552 contains a lot of changes in the generated files?

from sdk.

Ok that's awesome to hear! The problem is that we had a oneOf in the schema with simple types:

value:
  oneOf:
    - type: string
    - type: number
    - type: boolean

This is unfortunately not supported in most openapi-generator templates. There are quite a few issues on that (https://github.com/OpenAPITools/openapi-generator/search?q=oneof+string&type=issues - not all are relevant but maybe 10%).

What I did was basically removing that type and the leaving "value" type empty which implies that it is a polymorph type (could also be an object or array, which isn't the case actually, but better than something not working at all!)

from sdk.

Wohoo! I found the original tab with my findings

So I looked into this a bit more and I can't seem to come up with a good solution (also I don't have Java skills...). Basically the problem is this.

The value object of node.attributes.value is a polymorph simple type (string, bool, number, null). In OpenAPI Spec we use a ref and oneOf to express that:

          "value": {
            "$ref": "#/components/schemas/uiNodeInputAttributesValue"
          }

      "uiNodeInputAttributesValue": {
        "oneOf": [
          {
            "description": "The input's value.",
            "nullable": true,
            "type": "string"
          },
          {
            "description": "The input's value.",
            "nullable": true,
            "type": "number"
          },
          {
            "description": "The input's value.",
            "nullable": true,
            "type": "boolean"
          }
        ]
      },

Unfortunately we cannot do

      "value": {
        "oneOf": [
          {
            "description": "The input's value.",
            "nullable": true,
            "type": "string"
          },
          {
            "description": "The input's value.",
            "nullable": true,
            "type": "number"
          },
          {
            "description": "The input's value.",
            "nullable": true,
            "type": "boolean"
          }
        ]
      }

as that generates code in Java which would not compile due to a bug in openapi-generator. The interim step with the $ref appears to trick the Java generator into thinking that the element under value is an object while it really is a string, a number, or a boolean. This then causes the deserialization issue!

In Java, the value type is:

  public static final String SERIALIZED_NAME_VALUE = "value";
  @SerializedName(SERIALIZED_NAME_VALUE)
  private UiNodeInputAttributesValue value;

with a simple class

public class UiNodeInputAttributesValue {

backing it. UiNodeInputAttributesValue itself is basically seen as a dumb object instead of polymorphism. After digging through some issues, this appears to be a general problem / limitation of openapi-generator for several languages right now:

• OpenAPITools/openapi-generator#8457
• OpenAPITools/openapi-generator#15
• ... and a couple more

So in the end I think it's better to just not have any typing here even though the typing appears to be correct.

from sdk.

@aeneasr thanks for the clarifying what is happening. Just so I understand, currently the best option for any user that's not using Golang nor Typescript is to wait for next release?

For the time being, I use db67552 directly, just thinking that maybe users need to be informed about it.

from sdk.