You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
format:int64 parameter throws data mismatch error #407
openapi: "3.0.0"info:
version: 1.0.0title: Swagger Petstoredescription: A sample API that uses a petstore as an example to demonstrate features in the OpenAPI 3.0 specificationtermsOfService: http://swagger.io/terms/contact:
name: Swagger API Teamemail: apiteam@swagger.iourl: http://swagger.iolicense:
name: Apache 2.0url: https://www.apache.org/licenses/LICENSE-2.0.htmlservers:
- url: http://petstore.swagger.io/apipaths:
/users:
post:
summary: Adds a new userrequestBody:
content:
application/xml:
schema: # Request body contents$ref: '#/components/schemas/User'example: # Sample objectid: 10name: Jessica Smithresponses:
'200':
description: OKcomponents:
schemas:
User: # Schema nametype: objectproperties:
id:
type: integerformat: int64name:
type: string
I am getting this error in diagnostics:
Data and type mismatch found. [#/paths/~1users/post/requestBody/content/application~1xml/example/id
If I remove format:int64 in the id definition, the error goes away. I don't understand what's wrong here, how should int64 format look like? 10 is not a valid value in long format??
Version 1.1.1 didn't throw this error, I started getting it after updating to 1.1.3 sample.txt
This definitely seems like a bug to me. I actually don't think we should be returning errors at all for examples that don't match the schema. They should only be warnings. However, what you are showing is worse because you actually have a valid number.
So apparently its parsing the integers at strings since it sees them as an "any type"
This can be fixed in the current version by nesting the example inside of a value attribute (see below. the attach function wasn't working).
However, if you do this then the swagger ui's don't work that well. When you past the below yml into https://editor.swagger.io/ it sees "value" as part of the output.
openapi: "3.0.0"
info:
version: 1.0.0
title: Swagger Petstore
description: A sample API that uses a petstore as an example to demonstrate features in the OpenAPI 3.0 specification
termsOfService: http://swagger.io/terms/
contact:
name: Swagger API Team
email: apiteam@swagger.io
url: http://swagger.io
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
servers:
- url: http://petstore.swagger.io/api
paths:
/users:
post:
summary: Adds a new user
requestBody:
content:
application/xml:
schema: # Request body contents
$ref: '#/components/schemas/User'
example: # Sample object
value:
id: 10
name: Jessica Smith
responses:
'200':
description: OK
components:
schemas:
User: # Schema name
type: object
properties:
id:
type: integer
format: int64
name:
type: string
Activity
darrelmiller commentedon Aug 23, 2019
This definitely seems like a bug to me. I actually don't think we should be returning errors at all for examples that don't match the schema. They should only be warnings. However, what you are showing is worse because you actually have a valid number.
david-jessee commentedon Apr 5, 2020
So apparently its parsing the integers at strings since it sees them as an "any type"
This can be fixed in the current version by nesting the example inside of a value attribute (see below. the attach function wasn't working).
However, if you do this then the swagger ui's don't work that well. When you past the below yml into https://editor.swagger.io/ it sees "value" as part of the output.
Merge pull request #588 from /issues/407