@MilkeeyCat You can achieve a similar solution using by overriding the property type in overlay.yaml

This PR looks good!
I have successfully tested this on my local environment, and it works as expected.

It would be even better if you could add or update a test.

For example, you might want to consider adding a paths in:

file: internal/test/schemas/schemas.yaml
line: 150
content:

  /issues/1914:
    post:
      operationId: Issue1914
      description: |
        Ensure that anonymous inner types are generated correctly.
      requestBody:
        content:
          text/plain:
            schema:
              type: string
              format: uuid

and then run make generate on this repository root.

Thanks!

Looking at this, I'm wondering if we should put in a wider fix, which is that we try and convert the type to a string i.e. with fmt.Sprintf or something similar, so we end up returning something rather than hitting the compilation error - thoughts?

so we end up returning something rather than hitting the compilation error - thoughts?

Hm, honestly I prefer compilation error over incorrectly stringified value

Hmm - I get your thinking, but also not sure 🤔 I've raised #1975 in the meantime, let's see what some others think about the behaviour 👍

Maybe let's add a compatibility-option to disable the fallback?

I don't understand what fallback you're talking about, but #1975 looks good to me

Thanks - so I'm thinking we could add an entry into the CompatibilityOptions to allow us to push #1975 through as-is, but allow folks to opt-in to "I want to have a compilation error when there's not a String() method on the type" which would be best of both worlds?

With the way #1975 is done I personally don't think this option is needed.

... allow folks to opt-in to "I want to have a compilation error when there's not a String() method on the type"

How would that work with integer, string types? They don't have .String() method

With the way #1975 is done I personally don't think this option is needed.

... allow folks to opt-in to "I want to have a compilation error when there's not a String() method on the type"

How would that work with integer, string types? They don't have .String() method

Ah yeah, so we'd probably have the fallback of "if someone's using the compatibility option for the fallback, use string(body), and if they're not, use fmt.Sprintf(...)"

I think that automatically looking for a Stringer implementation via a safe type cast is about as good as we can do.

Marshaling primitive types as text/plain makes sense.

In the case of having text/plain media types for complex types, I think we should error out, the question is where to do it. We could look for a stringer implementation at runtime, and if one is there, use that. The way the code works currently is that on the server side, it's up to the user how to encode something as text/plain, we stay out of it.

If a user wants to do some fancy text encoding on complex types, let them implement Stringer manually on those types.

Ok, I think the way this should work is that we don't even look at UUID explicitly, the flow would be:

if json:
  ...
elif form
  ...
elif text:
   if bodyStringer, ok := body.(fmt.Stringer); ok : 
      bodyReader = strings.NewReader(bodyStringer.String())
   else if is_primitive_type(body):
      bodyReader = strings.NewReader(string(body))
    else:
      return error

The is_primitive_type(body) can be deduced by the codegen and provided as a template context flag.

Not having a codegen error allows a person to implement stringer. If they don't, they're going to get a runtime error.

It looks like PR #1975 is close to what I want, so I think it supersedes this PR.

Thanks for this - we've gone with #1975, as it handled a couple of extra things