OpenAPI arrays are not respecting spec?

ServiceStack Open API
1

Hello,

I’m using V5.9.0 and it looks like the OpenAPI feature generates an invalid definition for arrays. The values for items have their own value property which does not seem to be valid according to the specification.

I tried rewriting the items property myself in an OpenAPI filter like so:
image
but the result is the same. How can I remove that value property?

Generated JSON:

          "IEnumerable_TaskInfo_": {
            "title": "IEnumerable<TaskInfo>",
            "type": "array",
            "items": {
               "$ref": {
					"value": "#/definitions/TaskInfo"
				}
            }

I am expecting something like this:

          "TaskInfos": {
            "title": "TaskInfos",
            "type": "array",
            "items": {
               "$ref": "#/definitions/TaskInfo"
            }
2

I can’t repro this, all List<T>, T[] and IEnumerable<T> all generate the expected "items" { "$ref": "ref" }.

Also you shouldn’t be using interface properties in DTOs, i.e. just use the concrete List<T>.

What’s the actual DTO that generates this, it doesn’t look like it’s a property.

3

This took some time to figure out. I found this somewhere deep in bootstrap of that application:

JsConfig<Dictionary<string, object>>.OnSerializingFn = SomeMethodToSerializeDictionaries

So the issue is not related to ServiceStack. Someone had the fantastic idea to customize the Dictionary<string, object> type and from what I see I have to keep this customization for backward compatibility. I’ll have to figure something out to fix this issue.

Is it possible to customize JsConfig for a specific request? I saw that it is possible to customize some properties from the client but it doesn’t look like I can change the serialization for a specific type.

I doubt it is possible but it would help if I could ignore that custom JsConfig<Dictionary<string, object>> serialization in the /openapi request.

4

No it’s not possible and IMO relying on customizing core collections like Dictionary<string, object> is a bad idea, it’s used extensively in #Script and you’re likely to break other features.

5

I agree that’s it is a bad idea however I cannot easily go back on decision that were made ~10 years ago regarding that project. Thankfully we have no plan to use #Script so we won’t break that at least :slight_smile: .

Thanks for your help.

6

It’s also anywhere #Script is being used, e.g. in Declarative Validation. Either way messing with generic collections can cause runtime issues.