mrhid6
9df4a29210
swag v2.0.0-rc5's parseSecAttributesV3 resolves a security scheme's map key via getSecurityDefinitionKey(lines), which scans from the start of whatever comment-line slice it was handed and returns the first @securitydefinitions match — ignoring the current parse position entirely. Three @securityDefinitions.apikey blocks stacked in one Go comment group (the three were separated only by bare '//' lines, which do not split an ast.CommentGroup) therefore all resolved to the first block's name (cookieAuth), with the last block's in/name/description winning: the generated document had exactly one securityScheme, keyed cookieAuth, body esoAuth. Separating the three blocks with real blank source lines splits them into three distinct ast.CommentGroups, so swag's file-level comment scan (which requires no other tokens between them, same rule Go uses for doc comments) hands each block its own line slice and each resolves its own key. Regenerated openapi.json now carries all three schemes with correct bodies, referenced with no dangling security requirements.