[SPE-2004] Support `const` and `default` attributes [Other languages] about speakeasy HOT 3 CLOSED

Hi,

We have a discriminator (generated via FastAPI/Pydantic Literal')

It generates the following snippets in the OpenAPI spec, however the speakeasy cli fails with:
ERROR validation error: [line 280] discriminator mapping ref #/components/schemas/Distribution must have a property named style of type string or enum ERROR failed to generate SDKs for python ✖

      "Distribution": {
        "properties": {
          "style": {
            "const": "distribution",
            "title": "Style",
            "default": "distribution"
          }
        },
        "type": "object",
        "title": "Distribution",
        "description": "Pydantic class for when we want the distribution on a particular date."
      }

          "statistic": {
            "oneOf": [
              {
                "$ref": "#/components/schemas/Mean"
              },
              {
                "$ref": "#/components/schemas/Quantile"
              },
              {
                "$ref": "#/components/schemas/Distribution"
              }
            ],
            "title": "Statistic",
            "discriminator": {
              "propertyName": "style",
              "mapping": {
                "distribution": "#/components/schemas/Distribution",
                "mean": "#/components/schemas/Mean",
                "quantile": "#/components/schemas/Quantile"
              }
            }
          }

It seems it is failing on the missing "type" tag on "Distribution", however the swagger editor is able to determine it correctly.

Is this related to implying types from const/default attributes not being supported?

from speakeasy.

Hi @fergusdixon thanks for the issue report.

So looking through the schemas you provided above the issue you are seeing is because your style schema doesn't have a type attribute like type: string.

We rely on strong typing in your OpenAPI spec as much as possible to ensure we are generating the right types, so when a type isn't present we treat it as a generic any type which in this case fails our validation for discriminators because we are try to ensure they are strings.

While json-schema does allow for loose typing like this and assumptions on the type of the schema being made on heuristics around what other properties are present in the schema, we do little of that ourselves except where we can be pretty confident we have the type right, for example if you have a properties field or an items field in your schema we can be pretty sure its either an object or array you intended for the type of the schema. But for things like deducing the type is a string from const or default values that requires as to parse those values as json and try and deduce the type but that is error prone especially if the string values might contain a date or number for example.

So we just don't assume type in these situations and required it to be explicitly defined.

Hope that provides some context around why this is failing

from speakeasy.

Hey, thanks for the clarification and definitely makes sense. Frustrating that the FastAPI/Pydantic Literal types don't include this. I think we can find a workaround using Field(json_schema_extra={"type": "string"} on the Literal fields to force that verbose typing

from speakeasy.