Skip to content

Allow generating a list of strict operation IDs#2414

Open
AnthonySuper wants to merge 2 commits into
oapi-codegen:mainfrom
AnthonySuper:add-ability-to-list-all-operation-ids
Open

Allow generating a list of strict operation IDs#2414
AnthonySuper wants to merge 2 commits into
oapi-codegen:mainfrom
AnthonySuper:add-ability-to-list-all-operation-ids

Conversation

@AnthonySuper

Copy link
Copy Markdown

The generated code presently passes a strict operation ID to every StrictMiddlewareFunc you have configured for a server. This is great for writing auth-like middleware: you can have a unified function that handles authorization on the operational level, and test it by itself.

This is not so great if you're forgetful (like the author of this MR) and sometimes forget to write those tests... or to update your handler function.

By generating a list of all operation handlers, we make it much easier to write a test that asserts that some StrictMiddlewareFunc has proper behavior for all operation IDs. Something like:

func Test_MapOperationToPermissionsReturnsValuesForAllOperations(t *testing.T) {
	for _, operation := range server.StrictOperationIDs {
		t.Run(operation, func(t *testing.T) {
			permissions, err := MapOperationToPermissions(operation)
			assert.NoError(t, err)
			assert.NotEmpty(t, permissions)
		})
	}
}

@AnthonySuper
AnthonySuper requested a review from a team as a code owner June 18, 2026 16:32
The generated code presently passes a strict operation ID to every
`StrictMiddlewareFunc` you have configured for a server. This is great
for writing auth-like middleware: you can have a unified function that
handles authorization on the *operational* level, and test it by itself.

This is not so great if you're forgetful (like the author of this MR)
and sometimes forget to write those tests... or to update your handler
function.

By generating a list of all operation handlers, we make it much easier
to write a test that asserts that some `StrictMiddlewareFunc` has proper
behavior for *all* operation IDs.
@AnthonySuper
AnthonySuper force-pushed the add-ability-to-list-all-operation-ids branch from bff9920 to 4382333 Compare June 18, 2026 16:34
@greptile-apps

greptile-apps Bot commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR adds an optional generated list of strict operation IDs. The main changes are:

  • New strict-operation-list generation option in config and schema.
  • New StrictOperationIDs output template and codegen path.
  • New operation-list test fixture covering the basic generated slice.

Confidence Score: 3/5

This should be fixed before merging.

  • Alias paths can add operation IDs that strict middleware never receives.
  • Specs with a generated StrictOperationIDs type can become uncompilable when the option is enabled.
  • The happy path is covered, but these edge cases affect the new feature’s contract.

pkg/codegen/codegen.go and pkg/codegen/templates/operation-list.tmpl

Important Files Changed

Filename Overview
pkg/codegen/codegen.go Adds strict operation list generation, but currently includes alias operations that strict middleware never sees.
pkg/codegen/templates/operation-list.tmpl Emits the new StrictOperationIDs variable with a fixed top-level name that can collide with generated symbols.
pkg/codegen/configuration.go Adds the YAML config field for the new generation option.

Reviews (1): Last reviewed commit: "Allow generating a list of strict operat..." | Re-trigger Greptile

Comment thread pkg/codegen/codegen.go
// argument to every StrictMiddlewareFunc call. Each entry is the normalized
// Go identifier for the operation (e.g. "ListUsers"), matching exactly what
// the strict handler passes when it invokes the middleware chain.
var StrictOperationIDs = []string{

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Global name can collide

StrictOperationIDs is emitted as a fixed top-level package symbol, but it is not checked against generated type names. If a spec already has a component schema named StrictOperationIDs, code generation can emit both type StrictOperationIDs ... and var StrictOperationIDs = []string{...} in the same package. Go rejects that as a redeclaration, so enabling this option can make an otherwise valid spec fail to compile.

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

Successfully merging this pull request may close these issues.

1 participant