Path's that are longer than 128 characters crash NSwag

[Place1]

I've got a bizarre bug here. If i have a path in my swagger/openapi spec that's 128 characters or longer then NSwag will crash with a Newtonsoft de-serialization exception. I couldn't reproduce it with newtonsoft directly, but here's my repro with nswag.core

using System;
using NSwag;

namespace Example
{

    class Program
    {
        static void Main(string[] args)
        {
            var doc = SwaggerYamlDocument.FromFileAsync("./test.yaml").Result;
            Console.WriteLine(doc);
        }
    }
}

swagger: '2.0'
info:
  title: 'example'
  version: '1.0.0'
paths:
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:
    get:
      tags:
        - Example
      operationId: MyExample
      responses:
        '200':
          x-nullable: true
          description: ''
          schema:
            type: string

In the above spec there are 129 a characters as the path. If you remove 1 so that there's 128 characters then it'll all work as expected.

Using yaml or json specs result in the same outcome.

Here's the error:

Unhandled Exception: System.AggregateException: One or more errors occurred. (Invalid property identifier character: ?. Path 'paths', line 1, position 79.) ---> Newtonsoft.Json.JsonReaderException: Invalid property identifier character: ?. Path 'paths', line 1, position 79.
   at Newtonsoft.Json.JsonTextReader.ParseProperty()
   at Newtonsoft.Json.JsonReader.ReadAndAssert()
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.SetPropertyValue(JsonProperty property, JsonConverter propertyConverter, JsonContainerContract containerContract, JsonProperty containerProperty, JsonReader reader, Object target)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateObject(Object newObject, JsonReader reader, JsonObjectContract contract, JsonProperty member, String id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Populate(JsonReader reader, Object target)
   at NJsonSchema.ExtensionDataDeserializationConverter.ReadJson(JsonReader reader, Type objectType, Object existingValue, JsonSerializer serializer)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.DeserializeConvertable(JsonConverter converter, JsonReader reader, Type objectType, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
   at NJsonSchema.Infrastructure.JsonSchemaSerialization.FromJsonAsync[T](String json, SchemaType schemaType, String documentPath, Func`2 referenceResolverFactory, IContractResolver contractResolver)
   at NSwag.SwaggerDocument.FromJsonAsync(String data, String documentPath, SchemaType expectedSchemaType, Func`2 referenceResolverFactory)
   at NSwag.SwaggerYamlDocument.FromYamlAsync(String data, String documentPath, SchemaType expectedSchemaType, Func`2 referenceResolverFactory)
   at NSwag.SwaggerYamlDocument.FromFileAsync(String filePath)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at Example.Program.Main(String[] args) in /Users/me/Example/Program.cs:line 11

[RicoSuter]

Looks like a Newtonsoft.Json limitation (?)

Using yaml or json specs result in the same outcome.

Yes, thats because yaml is just converted to json internally.

[Place1]

After digging deeper i've found the problem in YamlDotNet

There is a hardcoded MaxAliasLength that is enforced on all scalar properties during this method: CheckSimpleKey.

If the CheckSimpleKey() method returns false then this condition will be false and the library will instead write a ? character.

Feels good to get to the bottom of this, but it's a little anti-climactic. I'll open an issue in their repo about it

[RicoSuter]

Update: Wait until new version of YamlDotNet is released.