Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect loading of object property named default #5

Closed
danielgtaylor opened this issue Nov 4, 2022 · 4 comments
Closed

Incorrect loading of object property named default #5

danielgtaylor opened this issue Nov 4, 2022 · 4 comments
Assignees

Comments

@danielgtaylor
Copy link
Contributor

Hi 👋 I'm the author of Restish and am working on adding OpenAPI 3.1 support. First off - awesome project and thanks for taking the time to write this library! Migrating from kin-openapi to libopenapi has been mostly straightforward so far.

I ran into an interesting bug where JSON schemas with objects defined that have a property named default seem to get set as the *base.Schema.Default field when it should be either nil or the actual default. Here's a simple example that when run outputs the following:

$ go run ./bug
Works1 <nil>
Works2 map[foo:hello]
Fails map[type:string]      <--- this should be `nil`!

Here is the code. I would link to the Go playground but it times out, so you'll have to run locally.

package main

import (
	"fmt"

	"github.com/pb33f/libopenapi"
)

var data = `
openapi: "3.1"
paths:
  /works1:
    get:
      responses:
        "200":
          content:
            application/json:
              schema:
                type: object
                properties:
                  foo:
                    type: string
  /works2:
    get:
      responses:
        "200":
          content:
            application/json:
              schema:
                type: object
                default:
                  foo: hello
                properties:
                  foo:
                    type: string
  /fails:
    get:
      responses:
        "200":
          content:
            application/json:
              schema:
                type: object
                properties:
                  default:
                    type: string
                  foo:
                    type: string
`

func main() {
	doc, err := libopenapi.NewDocument([]byte(data))
	if err != nil {
		panic(err)
	}

	result, errs := doc.BuildV3Model()
	if len(errs) > 0 {
		panic(errs)
	}

	m := result.Model

	fmt.Println("Works1", m.Paths.PathItems["/works1"].Get.Responses.Codes["200"].Content["application/json"].Schema.Schema().Default)

	fmt.Println("Works2", m.Paths.PathItems["/works2"].Get.Responses.Codes["200"].Content["application/json"].Schema.Schema().Default)

	fmt.Println("Fails", m.Paths.PathItems["/fails"].Get.Responses.Codes["200"].Content["application/json"].Schema.Schema().Default)
}
@daveshanley
Copy link
Member

Hi Daniel. I know Restish well! Thanks for stopping by.

I'll look into this ASAP The library is super new, so I know I've missed a few things like this. Appreciate the feedback and for helping me make this library better.

@daveshanley daveshanley self-assigned this Nov 7, 2022
@daveshanley
Copy link
Member

daveshanley commented Nov 7, 2022

After investigating, I realized this was a bug I fixed a few days ago, but it's sitting in a feature branch that's not quite ready, it's stable and entirely usable, but there are some minimal breaking changes in it.

d01d36f

I'm close to having this feature ready (I need to bump coverage back up in some low-level models). You are free to use that branch (which isn't going to change much more now that it's 95% ready).

I'll be able to merge in the what-changed feature in a week or so, providing I stay on schedule

The branch is called what-changed-feat

@daveshanley
Copy link
Member

This fix has been merged into main, but the 1.2 release is not yet ready. There needs some more stress testing and fixes made on the what-changed feature. Once it's able to cope with some load and stress, I will create the 1.2 tag.

There are a few minor breaking changes, which I will document, but nothing major and nothing that has many effects beyond the low-level API.

@daveshanley
Copy link
Member

v0.2.0 is now available with this fix in place. Thank you for helping me make this a better tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants