fix(mothership): workflow name constraints

[Sg312]

Summary

Block duplicate workflow names

Type of Change

• Bug fix

Testing

Manual

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 22, 2026 9:27am

[greptile-apps]

Greptile Summary

This PR adds a duplicate workflow-name constraint to createWorkflowRecord in apps/sim/lib/workflows/utils.ts, preventing the copilot/AI tool path from creating two workflows with the same name inside the same folder. The app/api/workflows/route.ts already had its own independent check (it inserts directly rather than going through createWorkflowRecord), so this completes the coverage for the second code path.

Key findings:

• The error message "already exists in this folder" is inaccurate when folderId is null (root-level workflows). A root-level workflow lives in the workspace, not a folder.
• updateWorkflowRecord has no equivalent duplicate check, so renaming a workflow can still produce a name collision that createWorkflowRecord would have blocked.
• The check is a SELECT-before-INSERT without a database-level unique constraint, which means a small race-condition window exists, but this is a pre-existing concern shared with the route-level check.

Confidence Score: 4/5

• Safe to merge with a minor fix to the error message for root-level workflows.
• The core logic is correct and properly guards the copilot creation path against duplicate workflow names. The error message wording when folderId is null is misleading but not a blocking bug. The missing check in updateWorkflowRecord is a gap but is out of scope for a focused bug-fix PR. No data-loss or security concerns introduced.
• apps/sim/lib/workflows/utils.ts — review the error message for the null-folder case and consider adding a similar check to updateWorkflowRecord.

Important Files Changed

Filename	Overview
apps/sim/lib/workflows/utils.ts	Adds a duplicate-name guard to createWorkflowRecord using a SELECT before INSERT. The guard works correctly for the copilot/mutations code path, but the error message is misleading when folderId is null, and updateWorkflowRecord remains unguarded, meaning renames can still produce duplicates.

Sequence Diagram

sequenceDiagram
    participant Client
    participant API as /api/workflows (POST)
    participant Copilot as Copilot Tool Executor
    participant CWR as createWorkflowRecord()
    participant DB as Database

    Note over Client,DB: Direct API path (pre-existing check)
    Client->>API: POST /api/workflows {name, folderId}
    API->>DB: SELECT id WHERE name+folder match
    DB-->>API: duplicate? → 409 Conflict
    API->>DB: INSERT workflow (if no duplicate)

    Note over Client,DB: Copilot path (new check added by this PR)
    Client->>Copilot: create_workflow tool call {name, folderId}
    Copilot->>CWR: createWorkflowRecord(params)
    CWR->>DB: SELECT id WHERE name+folder match
    DB-->>CWR: duplicate? → throw Error
    CWR-->>Copilot: {success: false, error: message}
    CWR->>DB: INSERT workflow (if no duplicate)

Loading

Comments Outside Diff (1)

1. apps/sim/lib/workflows/utils.ts, line 516-526 (link)

   No duplicate check on rename

   updateWorkflowRecord can change a workflow's name (and even its folderId) but there is no duplicate-name guard equivalent to the one just added to createWorkflowRecord. A user can rename a workflow to the same name as an existing sibling, bypassing the constraint that this PR is trying to enforce.

   Consider adding the same SELECT-before-UPDATE check here, or at least validating when updates.name or updates.folderId is being modified.

_{Reviews (1): Last reviewed commit: "Fix lint" | Re-trigger Greptile}

[greptile-apps]

Misleading error message when no folder is selected

When folderId is null the workflow is at the workspace root, not inside a folder. The error message "already exists in this folder" is incorrect in that case — it should say "already exists in this workspace" (or "in the root") to avoid confusing users who didn't select any folder.

Suggested change

	throw new Error(
	`A workflow named "${name}" already exists in this folder. Use a different name.`
	)
	throw new Error(
	folderId
	? `A workflow named "${name}" already exists in this folder. Use a different name.`
	: `A workflow named "${name}" already exists in this workspace. Use a different name.`
	)

The same wording issue also exists in the already-present check in apps/sim/app/api/workflows/route.ts at line 237.