Some parts of the codebase already define typed string constants (e.g., PlotType in observability_custom_dashboard.go), but some API fields with documented valid values are left as plain strings without constants.
For example, in the TLS Subscription API:
TLSSubscription.State — valid values (pending, processing, issued, renewing, failed, retry) are documented in the API reference but not provided as constants. The ListTLSSubscriptionsInput.FilterState comment also omits failed and retry, which makes it easy to miss handling these states.TLSChallenge.Type — values like managed-dns, managed-http-cname appear in test fixtures, but I could not find them in the API reference or source comments.
Without predefined constants, users must cross-reference API docs, source comments, and test fixtures to discover valid values.
Would the maintainers be open to adding constants for these? Happy to submit a PR for the TLS subscription types if so.
Some parts of the codebase already define typed string constants (e.g.,
PlotTypeinobservability_custom_dashboard.go), but some API fields with documented valid values are left as plain strings without constants.For example, in the TLS Subscription API:
TLSSubscription.State— valid values (pending,processing,issued,renewing,failed,retry) are documented in the API reference but not provided as constants. TheListTLSSubscriptionsInput.FilterStatecomment also omitsfailedandretry, which makes it easy to miss handling these states.TLSChallenge.Type— values likemanaged-dns,managed-http-cnameappear in test fixtures, but I could not find them in the API reference or source comments.Without predefined constants, users must cross-reference API docs, source comments, and test fixtures to discover valid values.
Would the maintainers be open to adding constants for these? Happy to submit a PR for the TLS subscription types if so.