fix(sidebar): use client-generated UUIDs for stable optimistic updates

[waleedlatif1]

Summary

• Fix context menu showing wrong options on newly created folders/workflows
• Fix drag getting stuck on freshly created items
• Root cause: optimistic updates used temp IDs that got swapped to real UUIDs on server response, causing React key changes → component remount
• Client now generates stable UUIDs via crypto.randomUUID() and sends them to the server, eliminating the ID swap
• All 4 optimistic mutations fixed: create folder, duplicate folder, create workflow, duplicate workflow
• Server APIs validate UUID format and fall back to server-generated IDs if not provided

References

• UUIDs for Optimistic Updates
• TanStack Query: Optimistic Updates
• TanStack DB: Mutations
• MDN: crypto.randomUUID()
• Stripe: Idempotent Requests
• Stripe: Designing for Idempotency

Type of Change

• Bug fix

Testing

Tested manually

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 6, 2026 2:27pm

[cursor]

PR Summary

Medium Risk
Touches folder/workflow create+duplicate flows end-to-end (client optimistic state, API validation, persistence IDs), so regressions could surface as missing items, selection/expand state glitches, or new 400s on invalid UUIDs.

Overview
Optimistic create/duplicate operations now use client-generated UUIDs so React keys don’t change when the server responds, preventing remount-related sidebar issues.

Client mutations for folder/workflow create and duplicate now pass an id/newId, and the optimistic-mutation helper accepts variable-derived temp IDs; replacement logic also remaps selection/expanded state when an optimistic ID differs from the server ID.

Server routes for POST /api/folders, POST /api/workflows, and both duplicate endpoints now accept optional UUIDs (validated via zod) and fall back to server-generated IDs; folder API tests were updated to expect the new Invalid request data 400 behavior.

^{Written by Cursor Bugbot for commit 53ce268. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes two sidebar UX bugs (wrong context menu options and stuck drag behaviour on freshly created items) by eliminating the root cause: the swap between a temporary string ID (temp-folder-<timestamp>) and the real server UUID that happened on mutation success, which caused React to remount components via key changes. The fix shifts UUID generation to the client using crypto.randomUUID() before calling mutateAsync, then passes that ID to the server. The server validates it as a proper UUID and uses it as the primary key, so tempId === data.id on success and no key migration is needed.

Changes

• All four optimistic mutations (create folder, duplicate folder, create workflow, duplicate workflow) now receive a client-generated UUID and forward it to the corresponding API route.
• generateTempId in optimistic-mutation.ts is updated to accept variables so callers can derive the ID from the mutation payload.
• Server routes (/api/folders, /api/workflows, and both duplicate routes) accept an optional id/newId field validated as z.string().uuid(), falling back to crypto.randomUUID() if absent.
• replaceOptimisticEntry in folders.ts gains state-migration logic (for expandedFolders, selectedFolders, lastSelectedFolderId) for the edge case where the server does not accept the client ID.
• A selectedWorkflows migration is similarly added in workflows.ts.
• The test suite's expected error message is updated to match the new Zod-based validation response.

The implementation is sound and addresses the root cause effectively. Two minor concerns: (1) type-safety weakness in the Zustand setState updater return type, and (2) the new client-ID code paths lack automated test coverage, relying instead on manual testing.

Confidence Score: 4/5

• Safe to merge; the core fix is sound and well-scoped with only minor type-safety and test-coverage gaps
• The PR implements a correct and well-targeted fix for optimistic update stability by shifting UUID generation to the client. The implementation properly validates UUIDs on the server and maintains rollback mechanisms. Two concerns prevent a higher score: (1) the Zustand setState updater uses Record<string, unknown> which bypasses TypeScript property-level validation, potentially allowing typos in future changes; (2) the new client-provided ID feature lacks automated test coverage, though manual testing was performed. Neither concern creates a runtime bug in the current implementation, but both represent opportunities to strengthen the solution.
• apps/sim/hooks/queries/folders.ts (type safety), apps/sim/app/api/folders/route.test.ts (test coverage)

Important Files Changed

Filename	Overview
apps/sim/hooks/queries/folders.ts	Adds client-provided ID support and state migration logic in replaceOptimisticEntry; uses Record<string, unknown> return type from Zustand setState, which weakens TypeScript type safety on property names and value types
apps/sim/hooks/queries/workflows.ts	Adds client-provided ID and newId support for create/duplicate workflow mutations; selectedWorkflows state migration on ID mismatch is correctly scoped to onSuccess only
apps/sim/hooks/queries/utils/optimistic-mutation.ts	generateTempId signature updated to accept variables, enabling callers to derive the temp ID from mutation variables (e.g., use the client-provided UUID)
apps/sim/app/api/folders/route.ts	Adds Zod schema validation for folder creation including optional client UUID; falls back to server-generated UUID when not provided
apps/sim/lib/workflows/persistence/duplicate.ts	Accepts optional newWorkflowId and uses it when provided, falling back to crypto.randomUUID(); correct and safe
apps/sim/app/api/folders/route.test.ts	Updates expected error message from 'Name and workspace ID are required' to 'Invalid request data' to match Zod validation; no new tests for client-provided ID paths

Sequence Diagram

sequenceDiagram
    participant C as Client (React)
    participant Q as TanStack Query
    participant S as Zustand Store
    participant API as Next.js API Route
    participant DB as Database

    C->>C: crypto.randomUUID() → stableId
    C->>Q: mutateAsync({ id: stableId, ... })
    Q->>S: applyOptimisticUpdate(stableId, item)
    Note over S: UI renders with stableId key<br/>(no remount on success)
    Q->>API: POST /api/folders { id: stableId }
    API->>API: z.string().uuid().parse(id)
    alt Client ID valid
        API->>DB: INSERT with stableId
        DB-->>API: row with stableId
        API-->>Q: { folder: { id: stableId } }
        Q->>S: replaceOptimisticEntry(stableId, data)<br/>tempId === data.id → no key migration needed
    else Client ID rejected / not provided
        API->>DB: INSERT with crypto.randomUUID()
        DB-->>API: row with serverGeneratedId
        API-->>Q: { folder: { id: serverGeneratedId } }
        Q->>S: replaceOptimisticEntry(stableId, data)<br/>tempId ≠ data.id → migrate expandedFolders / selectedFolders
    end
    alt Mutation fails
        Q->>S: rollback(snapshot)
    end
    Q->>API: invalidateQueries (refetch)

Loading

Comments Outside Diff (2)

1. apps/sim/hooks/queries/folders.ts, line 128-156 (link)

   Record<string, unknown> return type from the Zustand setState updater bypasses TypeScript's property-level type checking. A misspelled key (e.g. expandedFolder instead of expandedFolders) or an incorrect value type would silently compile without error.

   Consider using Partial<typeof state> instead to ensure TypeScript validates every property name and value type against the actual store shape:

   const update: Partial<typeof state> = {
     folders: {
       ...remainingFolders,
       [data.id]: data,
     },
   }
   
   if (tempId !== data.id) {
     const expandedFolders = new Set(state.expandedFolders)
     const selectedFolders = new Set(state.selectedFolders)
   
     if (expandedFolders.has(tempId)) {
       expandedFolders.delete(tempId)
       expandedFolders.add(data.id)
     }
     if (selectedFolders.has(tempId)) {
       selectedFolders.delete(tempId)
       selectedFolders.add(data.id)
     }
   
     update.expandedFolders = expandedFolders
     update.selectedFolders = selectedFolders
   
     if (state.lastSelectedFolderId === tempId) {
       update.lastSelectedFolderId = data.id
     }
   }
   
   return update

2. apps/sim/app/api/folders/route.test.ts, line 440-459 (link)

   The new client-provided UUID feature — the core of this PR — has no automated test coverage. The only test change updates the error message string. Consider adding test cases to verify the idempotency contract:

   • Creating a folder/workflow with a client-supplied valid UUID and verifying the response uses that UUID
   • Verifying that an invalid (non-UUID) client id is rejected with a 400
   • Verifying the server falls back to crypto.randomUUID() when id is omitted
   • Same cases for the duplicate routes (newId on POST /api/folders/[id]/duplicate and POST /api/workflows/[id]/duplicate)

   These tests would ensure the stable-ID guarantee doesn't regress in future changes.

_{Last reviewed commit: 53ce268}

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR