Description
Currently, openapi-2-kong enforces a strict 32-character limit on sanitized path parameters. When a transformation exceeds this limit, the process fails with:
path-parameter name exceeds 32 characters: '...' (sanitized to '...')
In many enterprise OpenAPI specifications, parameter names are often descriptive (e.g., organization_subscription_identifier) or generated from models that naturally exceed 32 characters. This forces manual renaming of parameters, which breaks the "source of truth" workflow of the OpenAPI document.
Relevant Code
The constraint is currently hardcoded in the SanitizeRegexCapture logic:
captureName := openapitools.SanitizeRegexCapture(varName, opts.InsoCompat)
if len(captureName) >= 32 {
return nil, fmt.Errorf("path-parameter name exceeds 32 characters: '%s' (sanitized to '%s')",
varName, captureName)
}
Proposed Solution
I would like to propose one of the following:
Increase the hard limit: Raise the limit to 64 or 128 characters to accommodate modern naming conventions.
Make it configurable: Add a CLI flag or option (e.g., --max-parameter-length) to allow users to override this limit at their own risk.
Thanks
Description
Currently, openapi-2-kong enforces a strict 32-character limit on sanitized path parameters. When a transformation exceeds this limit, the process fails with:
path-parameter name exceeds 32 characters: '...' (sanitized to '...')
In many enterprise OpenAPI specifications, parameter names are often descriptive (e.g., organization_subscription_identifier) or generated from models that naturally exceed 32 characters. This forces manual renaming of parameters, which breaks the "source of truth" workflow of the OpenAPI document.
Relevant Code
The constraint is currently hardcoded in the SanitizeRegexCapture logic:
Proposed Solution
I would like to propose one of the following:
Increase the hard limit: Raise the limit to 64 or 128 characters to accommodate modern naming conventions.
Make it configurable: Add a CLI flag or option (e.g., --max-parameter-length) to allow users to override this limit at their own risk.
Thanks