Deployment Issues with YAML

[Harish123]

Hi All,

We are using OAS Spec validation policy to validate the incoming request against the yaml in our API Proxy. While deploying the Proxy we are getting below issues.

S.NO	Issue	Error	WorkAround
1	OAS Validation policy with OAS 3.0.0 spec: YAML Parsing and Apigee deployment fails when when an example has a floating point number in them that is defined as schema number	instance "euw2-instance" reported error entities.ConfigurationFailed: "Configuration failure: Caused by: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.core.StreamReadConstraints com.fasterxml.jackson.dataformat.yaml.YAMLParser.streamReadConstraints()'\n\tat com.fasterxml.jackson.dataformat.yaml.YAMLParser._parseNumericValue(YAMLParser.java:1109)\n\tat com.fasterxml.jackson.core.base.ParserBase.getNumberType(ParserBase.java:678)\n\tat com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._fromFloat(JsonNodeDeserializer.java:751)\n\tat com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._deserializeContainerNoRecursion(JsonNodeDeserializer.java:576)\n\tmore..."	Have examples for schema type number that do not have a decimal place example: 6 rather than example: 6.5
2	OAS Validation policy with OAS 3.0.0 spec: YAML Parsing and Apigee deployment fails format: YYYY-MM-DD is rejected with schema: string	invalid paths: unsupported 'format' value "YYYY-MM-DD"	"date" works
3	OAS Validation policy with OAS 3.0.0 spec: YAML Parsing and Apigee deployment fails format: Date is rejected invalid paths: unsupported 'format' value "YYYY-MM-DD"	invalid paths: unsupported 'format' value "Date"	"date" works
4	OAS Validation policy with OAS 3.0.0 spec: YAML Parsing and Apigee deployment fails for $ref: '#/paths/~1customerOrder~1v1~1pnco~1v1/post/requestBody/content/application~1json/schema/properties/ProcessNewCustomerOrderRequest/properties/mobileOrder/allOf/1/properties/spendCapDetails/properties/spendCapAmount'	instance "euw2-instance" reported error steps.oasvalidation.OasCompilationFailed: "OASValidation : Compilation of OASResource oas://CustomerOrder.yaml failed with error:com.atlassian.oai.validator.OpenApiInteractionValidator$ApiLoadException: Unable to load API spec from provided URL or payload:\n\t- null"	Have $refs defined differently (to be discussed & agreed)
5	OAS Validation policy with OAS 3.0.0 spec: YAML Parsing and Apigee deployment fails format: dateTime is rejected invalid paths: unsupported 'format' value "dateTime"	instance "euw2-instance" reported error steps.oasvalidation.OasCompilationFailed: "OASValidation : Compilation of OASResource oas://CustomerOrder.yaml failed with error:com.atlassian.oai.validator.OpenApiInteractionValidator$ApiLoadException: Unable to load API spec from provided URL or payload:\n\t- null"	"date-time" works

Can anyone help why these issues occurs?

@kurtkanaskie @dchiesa1@Sai Saran Vaidyanathan@dknezic @ganadurai @Manish_Chennu @shrenikkumar-s @Renuka_atnoor 

[dchiesa1]

I believe this is a "known issue" and the ops team is working on a solution.  Have you contacted Apigee support. ?

[shrenikkumar-s]

An update:
1) Resolved: Apigee Engineering has rolled back a release revision that was affecting proxies with specific OAS specs in this way. The rollback should have addressed this issue. Please re-try the deployment and let us know if any issue persists.
However, unsure how the fix was pushed, via the Runtime upgrade or some other means? Can somebody throw some light on this?

2) 3) & 5) Workarounds to be used and they're fairly simple.

4) WIP: Accepted as a valid observation and someone from Apigee support are looking into this

[shrenikkumar-s]

Another one with a mention of workaround 🙂

6

Circular references, it gets into infinite loop. For example: customerOrderChannel (part of Order) has an element subChannel whose schema refers back to it i.e. customerOrderChannel

Deployment errors instance "euw2-instance" reported error entities.ConfigurationFailed: "Configuration failure: Caused by: java.lang.StackOverflowError\n\tat com.atlassian.oai.validator.util.OpenApiLoader.excludeBase64PatternFromEachValue(OpenApiLoader.java:157)\n\tat com.atlassian.oai.validator.util.OpenApiLoader.excludeBase64PatternFromSchema(OpenApiLoader.java:165)\n\tat com.atlassian.oai.validator.util.OpenApiLoader.excludeBase64PatternFromSchema(OpenApiLoader.java:167)\n\tat com.atlassian.oai.validator.util.OpenApiLoader.lambda$excludeBase64PatternFromEachValue$8(OpenApiLoader.java:157)\n\tmore..."

Use a schema for subChannel that's not circular (i.e. has same elements defined as one set)

[dchiesa1]

---

@shrenikkumar-s wrote:

However, unsure how the fix was pushed, via the Runtime upgrade or some other means? Can somebody throw some light on this?

---

The Apigee operations team rolled out a Runtime upgrade which led to the problem.  They then rolled back that update to avoid the problem.  

[Abhijeet1]

Hello @shrenikkumar-s 

Regarding circular references, it will soon be published as a known issue in the Apigee known issue document .

As a workaround, please avoid using circular references until then.