You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Duration validation incorrectly rejects valid values with zero fractional digits #1847
requires at least one of the three fractional digits to be non-zero.
As a result, values such as the following are rejected:
0.000s
1.000s
12.000s
999.000s
although they are within the documented range.
Additionally, the two alternatives in the regex are not grouped. Therefore, the ^ anchor applies only to the first alternative and the $ anchor only to the second alternative.
Expected behavior
The provider should accept all correctly formatted duration values between 0s and 999.999s.
For example:
0s
1s
999s
0.100s
1.000s
12.345s
999.999s
If one to three fractional digits are supported, the validation regex could be:
^[0-9]{1,3}(?:\.[0-9]{1,3})?s$
If exactly three fractional digits are required whenever a fractional part is specified, the regex could instead be:
^[0-9]{1,3}(?:\.[0-9]{3})?s$
Environment
OS: Windows / WSL Ubuntu
Terraform version (see terraform --version): OpenTofu v1.12.6
Version of the STACKIT Terraform provider: 0.110.0
Additional information
The validation rule and the validation error message appear to be inconsistent.
The error message states:
The duration must be between 0s and 999.999s (e.g.: 1s or 0.100s or 12.345s)
Based on this description, values such as 1.000s should be valid because they are correctly formatted and fall within the specified range.
I can take this. The same pattern is used for interval, interval_jitter and timeout in the ALB health check, so I would replace all three with one anchored pattern and add validator tests. Should it keep the documented 0s to 999.999s range (^[0-9]{1,3}(?:\.[0-9]{1,3})?s$), or follow the looser pattern in the ALB API spec?
Ideally, the Terraform provider should use the same effective validation as the internal implementation for interval, interval_jitter, and timeout.
If the internal implementation follows the ALB API specification, the provider should use the same pattern. However, it would be good to verify whether negative durations are actually supported for these health-check fields, as the API specification regex allows values such as -1s.
The validator tests, documentation, and error messages should then be aligned with the effective backend validation.
Hi @slimzghal,
Thank you for bringing this to our attention. This validation is there because it prevents a state drift of the API in Terraform. Currently, we're not planning to do a workaround for that in Terraform.
Best regards,
Manuel from the STACKIT Developer Tools Team
Activity
mittalpk commentedon Oct 22, 2026
I can take this. The same pattern is used for
interval,interval_jitterandtimeoutin the ALB health check, so I would replace all three with one anchored pattern and add validator tests. Should it keep the documented 0s to 999.999s range (^[0-9]{1,3}(?:\.[0-9]{1,3})?s$), or follow the looser pattern in the ALB API spec?slimzghal commentedon Oct 22, 2026
Thanks for taking this.
Ideally, the Terraform provider should use the same effective validation as the internal implementation for
interval,interval_jitter, andtimeout.If the internal implementation follows the ALB API specification, the provider should use the same pattern. However, it would be good to verify whether negative durations are actually supported for these health-check fields, as the API specification regex allows values such as
-1s.The validator tests, documentation, and error messages should then be aligned with the effective backend validation.
Manuelvaas commentedon Nov 2, 2026
Hi @slimzghal,
Thank you for bringing this to our attention. This validation is there because it prevents a state drift of the API in Terraform. Currently, we're not planning to do a workaround for that in Terraform.
Best regards,
Manuel from the STACKIT Developer Tools Team