Describe the bug
During onboarding, creating a workspace succeeds at the DB level (the Workspace and the owner WorkspaceMember are persisted), but the user's Profile.onboarding_step is not updated atomically. The frontend then re-reads the onboarding state, sees workspace_create: false, and redirects the user back to the "Create your workspace" step. Because the slug already exists, it shows "Workspace URL is already taken!" — leaving the user permanently stuck, unable to finish onboarding or reach the workspace they just created.
Steps to reproduce
- Fresh instance; first user signs up and lands on
/onboarding/.
- Create a workspace (e.g. name
musuq, slug musuq).
- Instead of advancing, the app redirects back to "Create your workspace".
- Re-entering the same slug → "Workspace URL is already taken!". Infinite loop.
Expected behavior
After a successful workspace creation, onboarding_step.workspace_create and last_workspace_id should be set and the user should advance / land on the newly created workspace. Additionally, the frontend should treat "user already owns/belongs to a workspace" as a recoverable state and advance, instead of looping on an already-taken slug.
Actual behavior
The workspace exists and the user is its owner and an active member, yet the profile onboarding state never committed:
Profile.is_onboarded = False
Profile.onboarding_step = {workspace_create: False, profile_complete: False,
workspace_invite: False, workspace_join: False}
Profile.last_workspace_id = None
Workspace 'musuq' = exists, owner = <user>
WorkspaceMember = role 20 (Owner), is_active = True
So the workspace-create transaction succeeded but the onboarding-step update on the profile did not → non-atomic transaction between workspace creation and the profile onboarding-step update.
Workaround (DB)
from plane.db.models import User, Workspace, Profile
u = User.objects.get(email="<user-email>")
w = Workspace.objects.get(slug="<slug>")
p = Profile.objects.get(user=u)
p.onboarding_step = {"workspace_join": True, "profile_complete": True,
"workspace_create": True, "workspace_invite": True}
p.is_onboarded = True
p.last_workspace_id = w.id
p.save()
After this, the user lands on the workspace normally.
Environment
- Plane self-hosted v1.3.1 (Docker), image
makeplane/plane-backend:v1.3.1
- Reverse proxy: Caddy behind Cloudflare Tunnel
- Browser: Chrome (desktop)
Describe the bug
During onboarding, creating a workspace succeeds at the DB level (the
Workspaceand the ownerWorkspaceMemberare persisted), but the user'sProfile.onboarding_stepis not updated atomically. The frontend then re-reads the onboarding state, seesworkspace_create: false, and redirects the user back to the "Create your workspace" step. Because the slug already exists, it shows "Workspace URL is already taken!" — leaving the user permanently stuck, unable to finish onboarding or reach the workspace they just created.Steps to reproduce
/onboarding/.musuq, slugmusuq).Expected behavior
After a successful workspace creation,
onboarding_step.workspace_createandlast_workspace_idshould be set and the user should advance / land on the newly created workspace. Additionally, the frontend should treat "user already owns/belongs to a workspace" as a recoverable state and advance, instead of looping on an already-taken slug.Actual behavior
The workspace exists and the user is its owner and an active member, yet the profile onboarding state never committed:
So the workspace-create transaction succeeded but the onboarding-step update on the profile did not → non-atomic transaction between workspace creation and the profile onboarding-step update.
Workaround (DB)
After this, the user lands on the workspace normally.
Environment
makeplane/plane-backend:v1.3.1