I think that unsorted SecurityDefinitions is the root cause. Some templates references SecurityDefinitions, so these also have the order problem.

• https://github.com/deepmap/oapi-codegen/blob/26bb06c00b13ddc6c26107402b8fa398be98ea29/pkg/codegen/templates/wrappers.tmpl#L28-L30
• https://github.com/deepmap/oapi-codegen/blob/950201251f59ac10642a6c332f3926da28d6fceb/pkg/codegen/templates/chi-middleware.tmpl#L41-L43
• https://github.com/deepmap/oapi-codegen/blob/26bb06c00b13ddc6c26107402b8fa398be98ea29/pkg/codegen/templates/templates.gen.go#L168-L170
• https://github.com/deepmap/oapi-codegen/blob/26bb06c00b13ddc6c26107402b8fa398be98ea29/pkg/codegen/templates/templates.gen.go#L879-L881

providerNameMap is generated from SecurityDefinitions. Just sorting the return value of DescribeSecurityDefinition probably solves these problems.

https://github.com/deepmap/oapi-codegen/blob/26bb06c00b13ddc6c26107402b8fa398be98ea29/pkg/codegen/operations.go#L184-L194

I think that unsorted SecurityDefinitions is the root cause. Some templates references SecurityDefinitions, so these also have the order problem.

SecurityDefinitions is a slice, so the order of iteration will be deterministic if elements are added in a deterministic order (which I'd guess is already happening, though I haven't verified this).

providerNameMap is generated from SecurityDefinitions. Just sorting the return value of DescribeSecurityDefinition probably solves these problems.

Sorting SecurityDefinitions (if it isn't already deterministically ordered) would not solve the problem with providerNameMap, since the order of iteration over a map is explicitly randomized by Go. We use the map for efficient deduplication, so we either need to sort the resulting contents (as is done in this PR), or use a different data structure for deduplication.

Sorry, I misunderstood because these are similar problems.

Sorting SecurityDefinitions (if it isn't already deterministically ordered) would not solve the problem with providerNameMap

Yes, I was wrong. However, SecurityDefinitions is not deterministically ordered. I'll create another issue and PR.

I've checked this problem on this PR branch.

test.yaml

openapi: 3.0.2
paths:
  /a:
    get:
      oparationId: a
      security:
        - ApiId: []
          ApiKey: []

components:
  ApiId:
    type: apiKey
    in: header
    name: X-Api-Id
  ApiKey:
    type: apiKey
    in: header
    name: X-Api-Key

$ diff -u <(go run ./cmd/oapi-codegen/ test.yaml) <(go run ./cmd/oapi-codegen/ test.yaml)
--- /dev/fd/11	2021-03-17 13:02:42.000000000 +0900
+++ /dev/fd/12	2021-03-17 13:02:42.000000000 +0900
@@ -251,10 +251,10 @@
 func (w *ServerInterfaceWrapper) GetA(ctx echo.Context) error {
 	var err error

-	ctx.Set(ApiKeyScopes, []string{""})
-
 	ctx.Set(ApiIdScopes, []string{""})

+	ctx.Set(ApiKeyScopes, []string{""})
+
 	// Invoke the callback with all the unmarshalled arguments
 	err = w.Handler.GetA(ctx)
 	return err