Allow generating a list of strict operation IDs - #2414
Conversation
Sorry, something went wrong.
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.
Greptile SummaryThis PR adds an optional generated list of strict operation IDs. The main changes are:
Confidence Score: 3/5This should be fixed before merging.
pkg/codegen/codegen.go and pkg/codegen/templates/operation-list.tmpl Important Files Changed
Reviews (1): Last reviewed commit: "Allow generating a list of strict operat..." | Re-trigger Greptile |
Sorry, something went wrong.
| // 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{ |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
Reviewers
At least 1 approving review is required to merge this pull request.
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: