Parsing error when path key exceeds 1023 characters

[ShaunLoganOracle]

Using v1.2.3 (also tried with 1.3.1-preview), I am getting a parsing error if the OA3 json has a path key that exceeds 1023 characters. For example, take the PetStore reference OA3 json and change the /pets path key to be extremely long. Attempt to read/parse the file, and get a parsing error:

Message: (Lin: 15, Col: 1032, Chr: 1302) - (Lin: 15, Col: 1033, Chr: 1303): While parsing a flow mapping,  did not find expected ',' or '}'.
Pointer: #line=15

Is this a known limitation? I don't see anything in the OA3 spec about a limit on key sizes. Is there any workaround?
Yes, the key seems excessively long, but it is generated by a customer's application which my product does not control.

Edit: Also, the error is fatal in that no other path entries get parsed - the Paths property on the oaDoc is empty.

Sample Code:

         var filepath = @"c:\temp\petstore-3.0-with-a-really-long-path.json";
         OpenApiStreamReader reader = new OpenApiStreamReader ();
         using (Stream file = new FileStream (filepath, FileMode.Open))
         {
            var oaDoc = reader.Read (file, out OpenApiDiagnostic diags);
            // expected: json to be parsed successfully
            // observed: error found 
            if (diags.Errors.Count > 0)
            {
               var error = diags.Errors.First ();
               Console.WriteLine ($"Found error(s), msg: {error.Message} ptr: {error.Pointer}");
            }
         }

Sample (long) Key:
/pets-with-a-really-long-path-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123

[darrelmiller]

Thanks for reporting this. It might be a limitation with the SharpYaml parser. I'm not aware of any limitation with the OpenAPI object model itself, although I don't think we have ever tried a path that long.

[ShaunLoganOracle]

Hi @darrelmiller , thanks for the reply. You are right, it is a limitation in SharpYaml. I'm wondering if there is a way to have OpenAPI.NET request from SharpYaml that the limit be higher, either by default or via some configuration mechanism (perhaps where the consumer of OpenAPI.NET would set the limit and have it get passed through to SharpYaml).

For us, this issue is a big concern, this is not just a speculative use case. We have real world customers generating OA3 json documents that have keys in the Paths Object that exceed the current limit. Since such keys result in fatal SemanticErrorExceptions from SharpYaml, this means that when such path is present, we don't get any useful Paths information in the resultant OpenApiDocument instance, and we are unable to proceed.

[darrelmiller]

@ShaunLoganOracle Question for you. If we were to update the JSON parsing to use System.Text.Json for faster parsing and if System.Text.Json does not have this limitation, would this be an sufficient workaround for this issue?

[ShaunLoganOracle]

@darrelmiller
Yes, this sounds promising (and who doesn't like faster parsing?).

[darrelmiller]

Work ongoing in #841