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.

Sign up for GitHub

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

Jump to bottom

panic: assignment to entry in nil map #2527

Closed
r1se opened this issue Mar 3, 2021 · 4 comments · Fixed by #3021
Closed

panic: assignment to entry in nil map #2527

r1se opened this issue Mar 3, 2021 · 4 comments · Fixed by #3021
Assignees
@fredbi
Labels
bug generator model Related to swagger generate model command pending PR

Comments

@r1se
Copy link

r1se commented Mar 3, 2021

Problem statement

swagger generate model --spec=/home/dvp/go/src/test/api/openapi/v1/swagger.yml 
2021/03/03 15:45:02 validating spec /home/dvp/go/src/test/api/openapi/v1/swagger.yml
2021/03/03 15:45:03 preprocessing spec with option:  minimal flattening
2021/03/03 15:45:03 building a plan for generation
2021/03/03 15:45:03 generation target ./
2021/03/03 15:45:03 planning definitions (found: 5)
2021/03/03 15:45:03 planning operations (found: 5)
panic: assignment to entry in nil map

goroutine 1 [running]:
github.com/go-swagger/go-swagger/generator.paramMappings(0xc000748660, 0xd9a41b, 0x3, 0xc001ebe3d0)
        /app/generator/operation.go:259 +0x91c
github.com/go-swagger/go-swagger/generator.(*codeGenOpBuilder).MakeOperation(0xc001f79d40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /app/generator/operation.go:324 +0x2ef
github.com/go-swagger/go-swagger/generator.(*appGenerator).makeCodegenApp(0xc000f0db00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /app/generator/support.go:339 +0x12b0
github.com/go-swagger/go-swagger/generator.(*appGenerator).Generate(0xc000f0db00, 0x0, 0x0)
        /app/generator/support.go:150 +0xa5
github.com/go-swagger/go-swagger/generator.GenerateModels(0x0, 0x0, 0x0, 0xc0001f4c80, 0x0, 0x0)
        /app/generator/model.go:63 +0xdc
github.com/go-swagger/go-swagger/cmd/swagger/commands/generate.(*Model).generate(0xc00031de60, 0xc0001f4c80, 0x0, 0x0)
        /app/cmd/swagger/commands/generate/model.go:85 +0xd8
github.com/go-swagger/go-swagger/cmd/swagger/commands/generate.createSwagger(0xee6140, 0xc00031de60, 0x0, 0x7fb5f369b298)
        /app/cmd/swagger/commands/generate/shared.go:184 +0x22d
github.com/go-swagger/go-swagger/cmd/swagger/commands/generate.(*Model).Execute(0xc00031de60, 0xc00041ee10, 0x0, 0x3, 0xc00031de60, 0x1)
        /app/cmd/swagger/commands/generate/model.go:98 +0xe5
github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc0003155c0, 0xc000032090, 0x3, 0x3, 0x10, 0xddcf70, 0x2a, 0xc690e0, 0xc0003215c0)
        /go/pkg/mod/github.com/jessevdk/go-flags@v1.4.0/parser.go:316 +0x89b
github.com/jessevdk/go-flags.(*Parser).Parse(...)
        /go/pkg/mod/github.com/jessevdk/go-flags@v1.4.0/parser.go:186
main.main()
        /app/cmd/swagger/swagger.go:137 +0xb65

Environment

swagger version: 0.26.1
go version: 1.15.8
OS: Ubuntu 18.04

swagger.zip
@fredbi fredbi added the bug label Mar 4, 2021
@fredbi fredbi self-assigned this Mar 4, 2021
@fredbi
Copy link
Contributor

fredbi commented Mar 4, 2021

Most likely similar to #2511

@lastchiliarch
Copy link

lastchiliarch commented Mar 24, 2021 •
edited

I'd like to help, Can I have a try?

@r1se
Copy link
Author

r1se commented Apr 8, 2021 •
edited by fredbi

@fredbi i'm using debugging, and see problem in mapping, when paths/parametrs it's ref on some definitions. In my case

  • $ref: '#/definitions/Exchange'

On code:
go-swagger/generator/operation.go line 253, we don't have p.Name if use ref

@fredbi fredbi added the model Related to swagger generate model command label Dec 22, 2023
@fredbi
Copy link
Contributor

fredbi commented Dec 23, 2023

ok so digging into that one again.

  1. First problem, the spec is invalid (the parameter pointed to by the $ref misses both name and in) and the validation doesn't detect it: on the surface, a parameter may be a $ref and the validate method doesn't check further
  2. Second problem, the panicking should be guarded - it is okay to try codegen with some tolerance, but we should avoid panic nonetheless

@fredbi fredbi mentioned this issue Dec 23, 2023
Closed
fredbi added a commit to fredbi/validate that referenced this issue Dec 23, 2023
@fredbi
fix(parameters): appled extra schema validation to parameters
e23d6bd 
This PR applies an extra jsonschema validation to expanded parameters.

Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only.
It is indeed valid to declare a parameter as a json reference.
The issue is that the contents of this parameter definition are subject only to "extra rules" (uniqueness, etc) and not the basic jsonschema rules (e.g. required properties).

An example is provided by go-swagger/go-swagger#2527.

It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared parameters normally point to is always fully expanded.

In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation.

* fixes go-openapi#165
* contributes go-swagger/go-swagger#2527

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
@fredbi fredbi mentioned this issue Dec 23, 2023
Merged
fredbi added a commit to fredbi/go-swagger that referenced this issue Dec 23, 2023
@fredbi
fix(codegen): fixed panic on invalid parameters in spec
b086cfb 
* fixes go-swagger#2527
* requires go-openapi/validate#166

TODO: add unit tests

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
@fredbi fredbi mentioned this issue Dec 23, 2023
Merged
fredbi added a commit to fredbi/validate that referenced this issue Dec 24, 2023
@fredbi
fix(parameters): applied extra schema validation to parameters
7ca958e 
This PR applies an extra jsonschema validation to expanded parameters.

Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only.
It is indeed valid to declare a parameter as a json reference.

The issue is that the expanded content of this parameter definition is subject only to "extra rules" (uniqueness, etc)
and not to the basic jsonschema rules (e.g. allowed and required properties).

An example is provided by go-swagger/go-swagger#2527.

It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared
parameters normally point to is always fully expanded.

In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation.

* fixes go-openapi#165
* contributes go-swagger/go-swagger#2527

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Dec 24, 2023
@fredbi
fix(codegen): fixed panic on invalid parameters in spec
1ee03cb 
* fixes go-swagger#2527
* requires go-openapi/validate#166

TODO: add unit tests

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/validate that referenced this issue Dec 27, 2023
@fredbi
fix(parameters): applied extra schema validation to parameters
5e4e2ec 
This PR applies an extra jsonschema validation to expanded parameters.

Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only.
It is indeed valid to declare a parameter as a json reference.

The issue is that the expanded content of this parameter definition is subject only to "extra rules" (uniqueness, etc)
and not to the basic jsonschema rules (e.g. allowed and required properties).

An example is provided by go-swagger/go-swagger#2527.

It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared
parameters normally point to is always fully expanded.

In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation.

* fixes go-openapi#165
* contributes go-swagger/go-swagger#2527

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to go-openapi/validate that referenced this issue Dec 27, 2023
@fredbi
fix(parameters): applied extra schema validation to parameters (#166)
1d1d938 
* fix(parameters): applied extra schema validation to parameters

This PR applies an extra jsonschema validation to expanded parameters.

Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only.
It is indeed valid to declare a parameter as a json reference.

The issue is that the expanded content of this parameter definition is subject only to "extra rules" (uniqueness, etc)
and not to the basic jsonschema rules (e.g. allowed and required properties).

An example is provided by go-swagger/go-swagger#2527.

It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared
parameters normally point to is always fully expanded.

In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation.

* fixes #165
* contributes go-swagger/go-swagger#2527

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

* added unit test to assert that no duplicate messages are spewed out

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

---------

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Dec 27, 2023
@fredbi
fix(codegen): fixed panic on invalid parameters in spec
60d325a 
* Added unit tests to assert that invalid parameters in spec
are indeed detected (i) by spec validation, (ii) by codegen when
validation is skipped.
* Refactored a bit client codegen tests

* fixes go-swagger#2527
* requires go-openapi/validate#166

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Dec 27, 2023
@fredbi
fix(codegen): fixed panic on invalid parameters in spec
d8918a9 
* Added unit tests to assert that invalid parameters in spec
are indeed detected (i) by spec validation, (ii) by codegen when
validation is skipped.
* Refactored a bit client codegen tests

* fixes go-swagger#2527
* requires go-openapi/validate#166

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit that referenced this issue Dec 27, 2023
@fredbi
fix(codegen): fixed panic on invalid parameters in spec
4e06e10 
* Added unit tests to assert that invalid parameters in spec
are indeed detected (i) by spec validation, (ii) by codegen when
validation is skipped.
* Refactored a bit client codegen tests

* fixes #2527
* requires go-openapi/validate#166

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
Assignees

@fredbi fredbi

Labels
bug generator model Related to swagger generate model command pending PR
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(codegen): fixed panic on invalid parameters in spec fredbi/go-swagger
3 participants
@lastchiliarch @r1se @fredbi