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

Flatten stopped processing nested directories in v0.26.0 #2743

Closed
nikitakalyanov opened this issue Mar 21, 2022 · 5 comments · Fixed by #3059
Closed

Flatten stopped processing nested directories in v0.26.0 #2743

nikitakalyanov opened this issue Mar 21, 2022 · 5 comments · Fixed by #3059
Assignees
Labels

Comments

@nikitakalyanov
Copy link

Problem statement

A certain structure of directories and files worked before v0.26.0 and stopped working after this version. It also does not work with the latest version either.

Swagger specification

https://github.com/nikitakalyanov/go-swagger-test

Steps to reproduce

https://github.com/nikitakalyanov/go-swagger-test

Environment

swagger version: 0.26.0
go version: 1.15.6
OS: Docker image

From the error message it seems that relative paths are now resolved differently. Could we document it somewhere then?
The workaround for now is to flatten the structure manually - i.e. remove the 'paths/' directory and put the mypath1.yml and mypath2.yml files at the root level.

@fredbi fredbi added flatten Related to spec flattening bug labels Dec 22, 2023
@fredbi
Copy link
Contributor

fredbi commented Dec 22, 2023

Yes, the previous behavior was incorrect, not resolving references from the current document's.
I can't remember exactly when this was fixed.
So now, references in the "paths" folder must reference to definitions as "../definitions/....yaml#...", which is more correct.

Like so:

get:
  produces:
    - "application/json"
  responses:
    200:
      description: "OK"
      schema:
        $ref: "../definitions/resp1.yml#/Resp1"
    500:
      description: "Internal server error"
      schema:
        $ref: "../definitions/errors.yml#/ErrorResponse"

I could verify that the specs flatten properly then.

@fredbi fredbi added question and removed bug labels Dec 22, 2023
@mateusbandeiraa
Copy link

There appears to be an inconsistency whether the path is resolved from the files directory instead of the root directory. This is what I mean:

Using fixtures\bugs\2258\bar.yml as a starting point for this example:

get:
  responses:
    200:
      description: OK
      schema:
        type: array
        items:
          $ref: '../user/index.yml#/User' ## this doesn't work
    500:
      description: OK
      schema:
        type: array
        items:
          $ref: './swagger/user/index.yml#/User' ## this works

(https://github.com/mateusbandeiraa/go-swagger/blob/2a8cb9362d05a9131d3278eb21f76152be1ff598/fixtures/bugs/2258/swagger/paths/bar.yml#L1-L14)

From what you said, the $ref should be '../user/index.yml#/User'. But this doesn't work. What actually works is './swagger/user/index.yml#/User'.

With the 200 response, here's the error message: could not resolve schema: open /go/user/index.yml: no such file or directory.
Without it, it completes the flattening correctly.

@fredbi
Copy link
Contributor

fredbi commented Jan 4, 2024

Running flatten with current master on fixture 2258. Seems to work as expected.

cd fixtures/bugs/2258
swagger flatten --format yaml fixture-2258.yaml 
2024/01/04 16:47:21 format =  yaml
swagger: "2.0"
info:
    title: Simple API
    version: 0.0.0
paths:
    /bar:
        get:
            responses:
                "200":
                    description: OK
                    schema:
                        $ref: '#/definitions/user'
    /foo:
        get:
            responses:
                "200":
                    description: OK
                "500":
                    description: OK
                    schema:
                        $ref: '#/definitions/errorPayload'
    /nested:
        get:
            responses:
                "200":
                    description: OK
                    schema:
                        $ref: '#/definitions/sameFileReference'
definitions:
    errorDetailsItem:
        description: Represents an item of the list of details of an error.
        properties:
            code:
                type: string
            details:
                items:
                    type: string
                type: array
            message:
                type: string
        required:
            - message
            - code
        title: Error details item
    errorPayload:
        properties:
            errors:
                items:
                    $ref: '#/definitions/errorDetailsItem'
                type: array
        required:
            - errors
        title: Error Payload
    model:
        properties:
            name:
                type: string
        type: object
    sameFileReference:
        properties:
            name:
                type: string
        type: object
    user:
        $ref: '#/definitions/model'

The bar.yml document is located in ./swagger/paths
It refers to another document in the sibling folder ../user/index.yml
So far so good.

I didn't quite understand what you tried to run and what doesn't work specifically.

@mateusbandeiraa
Copy link

Just pushed a tidier couple of examples.

Working:

image

get:
responses:
200:
description: OK
schema:
type: array
items:
$ref: './swagger/user/index.yml#/User' ## this works

https://github.com/go-swagger/go-swagger/tree/809195a882718648d9647ed12a44ab2071936ba0/fixtures/bugs/_working-example

Non-working:

image

get:
responses:
200:
description: OK
schema:
type: array
items:
$ref: '../user/index.yml#/User' ## this doesn't work

https://github.com/go-swagger/go-swagger/tree/809195a882718648d9647ed12a44ab2071936ba0/fixtures/bugs/_non-working-example

@fredbi fredbi added bug and removed question labels Jan 8, 2024
@fredbi
Copy link
Contributor

fredbi commented Jan 8, 2024

@mateusbandeiraa thanks for the detailed example. I've been able to reproduce your issue. It looks like this is a valid bug.

@fredbi fredbi self-assigned this Jan 8, 2024
fredbi added a commit to fredbi/spec that referenced this issue Jan 8, 2024
… resolution when SKipSchema

* fixes go-openapi#182
* contributes go-swagger/go-swagger#2743

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/analysis that referenced this issue Jan 8, 2024
This reproduces the $ref issue with relative paths in sibling folders
in responses (same applies to parameters, but not schemas).

Added a test to verify that:
* (i) the invalid path that used to work no longer does
* (ii) the valid path that used not to work now does

* contributes go-swagger/go-swagger#2743

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/analysis that referenced this issue Jan 8, 2024
This reproduces the $ref issue with relative paths in sibling folders
in responses (same applies to parameters, but not schemas).

Added a test to verify that:
* (i) the invalid path that used to work no longer does
* (ii) the valid path that used not to work now does

* contributes go-swagger/go-swagger#2743

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 8, 2024
* fixes go-swagger#2743

This PR onboards the fix to go-openapi/spec#182:
 * invalid relative path in $ref in schema for parameters or response
   when SkipSchema=true (flatten use-case)

Added a test to assert that the fix works fine with the version update.

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to go-openapi/spec that referenced this issue Jan 9, 2024
… resolution when SKipSchema (#183)

* fix(expand): parameters & responses should properly follow remote doc resolution when SKipSchema

* fixes #182
* contributes go-swagger/go-swagger#2743

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>

* fixed assertion in test for windows paths

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>

---------

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/analysis that referenced this issue Jan 9, 2024
This reproduces the $ref issue with relative paths in sibling folders
in responses (same applies to parameters, but not schemas).

Added a test to verify that:
* (i) the invalid path that used to work no longer does
* (ii) the valid path that used not to work now does

* contributes go-swagger/go-swagger#2743

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to go-openapi/analysis that referenced this issue Jan 9, 2024
This reproduces the $ref issue with relative paths in sibling folders
in responses (same applies to parameters, but not schemas).

Added a test to verify that:
* (i) the invalid path that used to work no longer does
* (ii) the valid path that used not to work now does

* contributes go-swagger/go-swagger#2743

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 9, 2024
* fixes go-swagger#2743

This PR onboards the fix to go-openapi/spec#182:
 * invalid relative path in $ref in schema for parameters or response
   when SkipSchema=true (flatten use-case)

Added a test to assert that the fix works fine with the version update.

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit that referenced this issue Jan 10, 2024
* fixes #2743

This PR onboards the fix to go-openapi/spec#182:
 * invalid relative path in $ref in schema for parameters or response
   when SkipSchema=true (flatten use-case)

Added a test to assert that the fix works fine with the version update.

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants