Multiple runs generate different swagger files / Flaky generation

[danielpoe]

Describe the bug Multiple runs of swag init result in different outputs

To Reproduce Steps to reproduce the behavior: 1 clone https://github.com/i-love-flamingo/flamingo-commerce 2 run "go generate" (this triggers swag init) 3 check git diff 4 repeat 2 to 3

Expected behavior deterministic result expected

Screenshots

Your swag version e.g. 1.6.6

Your go version e.g. 1.14

Additional context It is a bigger codebase and structs are references from different entries. My guess is that the cause is "Skipping 'domain.Media', already parsed." and depending which reference is first the result includes different types in the file

[sdghchj]

So you mean domain.Media is an alias of two or more different struct models?

[danielpoe]

Not sure what the reason is - I am not aware of the processing internals.

It also happens for "domain.Attribute" - this struct is present in two different "domain" packages (product/domain and category/domain). (I have even annotated them with @name) - but its still Flaky.

If you execute the generation multiple times you can see that the result is always different. My guess it somewhere a map is used (where range operation is random) and the processing is depending on the order.
(My other guess is that files are skipped once processed and maybe onlly referenced structs are evaluated?)

[sdghchj]

Try branch refactored. It will search the imports on the top of current source file for models.

[danielpoe]

Thanks for the prompt feedback.

This branch seems to be based on 1.6.5 and I get another error ( ParseComment error in file product/interfaces/controller/apicontroller.go :invalid type for field: Parent)

So I cannot say if the fix works

[sdghchj]

Branch refactored is kept synchronous with v1.6.6 , including all the major features, but references models in a more strict way. I see your repository has many complex struct models leading to problems:

1. big.Float imported from internal package math, skipped by swag, is directly taken as type string by branch master , but not found by branch refactored. So tag swaggertype:"string" is recommended.
2. Structs with mutual references or self-referenced members lead to recursively parsing bug. I have push a commit to fix it. However, I see swagger UI won't expand it in this case and I wonder what a scene will use a linked-list struct as API request or response. Tag swaggerignore:"true" is helpful, I think.
3. Since models are referenced in a more strict way in branch refactored, when you use a model with a package name in a comment above an API func，you have to import that package.

//api.go

import _ xxx/xxxx/domain

//@success 200 {object} domain.SomeWhat ""
func myApi(){
     //domain.SomeWhat is not referenced in code
}

[danielpoe]

Thanks for your feedback.

After annotaing the reported errors the result still is flaky at this points:

       dataValidationInfo:
         type: object
       error:
-        $ref: '#/definitions/controller.resultError'
+        $ref: '#/definitions/flamingo.me_flamingo-commerce_v3_cart_interfaces_controller.resultError'


...
     type: object
-  flamingo.me_flamingo-commerce_v3_product_interfaces_controller.resultError:
+  flamingo.me_flamingo-commerce_v3_payment_interfaces_controller.resultError:
... etc

------------Also a recursion error occurs where I think it should work:

//CategoryTeaser - Represents some Teaser infos for Category
	CategoryTeaser struct {
		//Code the idendifier of the Category
		Code string
		//The Path (root to leaf) for this Category - separated by "/"
		Path string
		//Name - speaking name of the category
		Name string
		//Optional link to parent teaser
		Parent *CategoryTeaser `swaggerignore:"true"`
	}

[danielpoe]

update: once I commented the "resultError" struct that appeared in multiple packages with a unique name the generated result seems to be stable

[sdghchj]

So have you fixed all your problems ?

[danielpoe]

Yes its working thanks for the support.

But I still think it should work without making the struct names unique vie @name annotation. Also I think the recursion error should not appear since its a valid type

[freddieptf]

I was also hitting the recursion error but the refactored branch helped! New error i'm now getting is ParseComment error in file *** :cannot find type definition: error on this struct

type JobResult struct {
	Job
	Time time.Time `json:"time"`
	Err  error     `json:"err"`
}

It works fine when i ignore the field but is that the intended behaviour?

[IvanMaidurov]

We encountered this issue also. When package and struct have the same name, but located in different places generation becomes flaky, whether you use @name or not.

solved by downgrading to version github.com/swaggo/swag v1.6.6-0.20200603163350-20638f327979, from what I see it was never merged and version 1.6.7 keeps the issue

[decentralgabe]

I'm still getting this issue.