Terraform states with `.` start returning `404` error if locking disabled and it was created previously without the `.` because it was being stripped
Summary
!105674 (merged) allows periods/dots to be used in terraform state objects in GitLab
This change allows everything in a Terraform state name except slashes. It's the same requirement as for namespaces and projects.
This solves a common confusion that when a state name contained a dot it resulted in a
404
The Gitlab-managed Terraform State Backend didn't allow certain characters in the state names - one of which was the dot .
. Most of the time trying to create such a state resulted in a 404 Not Found
error.
It seems though that some users managed to create a state with a .tfstate
suffix, e.g. terraform.tfstate
. However, the .tfstate
was just dropped and the state was actually being stored as terraform
only.
Now, with the aforementioned bug being fixed the .tfstate
is no longer dropped and the state name correctly becomes terraform.tfstate
.
The problem for those users who called the API with terraform.tfstate
stored as terraform
is that their state cannot be found now (because terraform.tfstate
doesn't exist for them, but terraform
does), resulting in a 404
error.
Affected Users
Affected users are most likely only those who disabled state locking and put a dot in their state names -> see fix.
The reason for this is that when locking, the state name is not the last part of the URL and nothing gets stripped (.../terraform/state/:name/lock
) and this resulted in a 404
- it's the first action to happen when locking is configured.
However, when it's not configured the user is able to create a state even when they provide a .
- but the actual state is just named with the part before the dot, because the part after the dot is stripped away. (probably by some NGINX configuration).
Reported:
- In a confidential issue (contains private customer details - link for GitLab team members)
- A support ticket (link for GitLab team members)
- Internal slack thread
Steps to reproduce
Attempt to use an existing terraform state file, named in GitLab without .tfstate
, but add .tfstate
to the filename.
What is the current bug behavior?
Requests for terraform state files with .tfstate
appended return a 404 if they do not exist.
What is the expected correct behavior?
The current behavior can be argued to be correct and the affected users are "victims" of a buggy behavior which has now changed to being correct.
Fix for affected users
Affected users can just remove the .tfstate
suffix to access their state and continue their operation.
If a user wants the .tfstate
suffix, they can migrate the state from the state without the suffix to a new state with the suffix and continue using that one as it's now properly supported.