-
Notifications
You must be signed in to change notification settings - Fork 887
Duplicate name when creating a new workspace build (transition): pq: duplicate key value violates unique constraint "workspace_builds_workspace_id_name_key"
#3038
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Another instance of this issue has manifested in https://github.com/coder/coder/runs/7429175788?check_suite_focus=true
We should add the ability to retry unique names until we find one in all places where we rely on them or enforce uniqueness. Edit: This looks like a test bug, originating from: coder/cli/templatedelete_test.go Line 60 in 87b0b4b
coder/coderd/coderdtest/coderdtest.go Line 369 in 87b0b4b
|
We are starting to run into test flakes due to lack of randomness in CI, this change simply bumps randomness by additional suffix numbers. See: #3038 (comment)
We are starting to run into test flakes due to lack of randomness in CI, this change simply bumps randomness by additional suffix numbers. See: #3038 (comment)
c.f. #1561 |
Thanks @spikecurtis, as described #1561 would solve the reported issue. There is one other place in particular where we would run into this issue: coder/coderd/templateversions.go Line 762 in 87b0b4b
ALTER TABLE ONLY template_versions
ADD CONSTRAINT template_versions_template_id_name_key UNIQUE (template_id, name); Then there's also this one, which might be lower priority since it's tied to the in-memory database? coder/coderd/provisionerdaemons.go Line 69 in 87b0b4b
ALTER TABLE ONLY provisioner_daemons
ADD CONSTRAINT provisioner_daemons_name_key UNIQUE (name); There are a few other uses of |
Closing this in favor of #1561. The context here is helpful! |
This is an issue we ran into CI, it's a rare occurrence but there's a non-zero chance it can happen to our users as well.
Problem: When a new workspace build is created for an existing workspace (e.g. transition into deleted) a new (unique-ish) name is generated for that job via
namesgenerator.GetRandomName(1)
. Normally this should not be an issue, but we have a unique constraint on(workspace_id, name)
:This results in a non-zero chance that both the create job and delete job receive the same
name
, resulting in the conflict. For very long lived workspaces, the chance of hitting this issue becomes greater. I did a local test that reproduced this after running workspace start/stop 200 times.The CI run that hit this issue: https://github.com/coder/coder/runs/7399324482?check_suite_focus=true
Questions
The text was updated successfully, but these errors were encountered: