OpenAPI appears to have broken for some object names

1

I’ve just upgraded to 5.0.2, and the generated OpenAPI export has a bizarre issue.
If we have an object named Stream the interface will only generate it as an empty object, whereas renaming it to stream will generate correctly:

"stream": {
  "title": "stream",
  "properties": {
    "Description": {
      "type": "string"
    },
    "Name": {
      "type": "string"
    },
    "ProjectId": {
      "type": "string",
      "x-nullable": false
    },
    "Streamid": {
      "type": "integer",
      "format": "int32",
      "x-nullable": false
    }
  },
  "description": "stream",
  "type": "object"
},

vs

"Stream": {
  "title": "Stream",
  "properties": {},
  "description": "Stream",
  "type": "object"
},

This has broken our CI build, as our generated typescript classes have all changed to <any> instead of <Stream>
We would rename the Stream class, but it’s generated from a database table called Stream, so that’s not a very attractive option (plus we don’t want to rework all our clients)

2

Do you have another Type returning the .NET Stream or IReturn<Stream> Type? Because if I haven’t registered a Stream Type /openapi will render:

   "Stream":{  
      "title":"Stream",
      "properties":{  
         "Streamid":{  
            "type":"integer",
            "format":"int32",
            "x-nullable":false
         },
         "Description":{  
            "type":"string"
         },
         "Name":{  
            "type":"string"
         },
         "ProjectId":{  
            "type":"string"
         }
      },
      "description":"Stream",
      "type":"object"
   }

But if I add a Service which uses a .NET Stream, e.g:

[Route("/return/stream")]
public class ReturnStream : IReturn<Stream>
{
    public byte[] Data { get; set; }
}

It only renders:

"Stream": {
    "title": "Stream",
    "properties": {},
    "description": "Stream",
    "type": "object"
},

Essentially because it conflicts with .NET’s built-in Type as there can only be 1 Type definition with the same name.

3

Hmm, interesting. No, I have no methods exporting a Stream, and if I rename Stream to StreamDto there is no longer a definition for Stream at all, which I assume there would be for your sample?

4

Ah, I found the cause, but it’s not as logical as you might think.
I recently had to implement IRequiresRequestStream on a method to get the raw JSON structure from the body, and even though the stream is never used by swagger it still appears to impact on the returned value.

1 Like
5

OK, so adding [IgnoreDataMember] prevents the issue:

[IgnoreDataMember]
    public Stream RequestStream { get; set; }

I think this needs to be included in the information re how to access the Request body, as it’s a bit of a hidden trap :smile: