fix(fork): preserve folder structure across a fork edge for files, tables, and knowledge bases - #6752

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 16, 2026 12:32am

PR Summary

Medium Risk
Touches fork transaction folder inserts and resource placement across four folder collections; behavior is forward-only and folder-ceiling checks can refuse syncs at cap, matching existing workflow-folder behavior.

Overview
Fork create and promote/sync no longer flatten copied files, tables, and knowledge bases to the target root. Each family now mirrors the source folder subtree (content folders plus ancestors, pruned branches omitted) via the same logic workflows already used.

resolveForkFolderMapping is parameterized by resourceType (workflow, file, table, knowledge_base) so each disjoint folder tree is mapped separately. Copied rows get remapped folderId values; unmapped folders still fall back to root.

Files: planForkFileCopies returns folderIdMap and sets optional targetFolderId on blob tasks; finalize writes that folder instead of always null. Older queued blob jobs without targetFolderId still finalize at root.

Fork create / promote: workflow, file, table, and KB folder maps are merged into one map for sim:folder/<id> rewriting in copied markdown/skills and related content refs.

^{Reviewed by Cursor Bugbot for commit a07e14b. Configure here.}

Greptile Summary

This PR extends fork folder preservation from workflows to files, tables, and knowledge bases in create and promote flows.

• Parameterizes folder mapping by resource family.
• Assigns mirrored target folders to copied resources and file-copy tasks.
• Merges all folder maps for content-reference rewriting.
• Adds coverage for file and knowledge-base folder placement.

Confidence Score: 4/5

The PR should not merge until the outstanding dangling-parent mapping defect is fixed, because copied content can be assigned to an unrelated target folder.

The shared mapper still converts an unresolved soft-deleted parent to a root-level mapping key and may reuse an unrelated same-named target folder; the new file, table, and knowledge-base paths consume that mapping directly.

Files Needing Attention: apps/sim/ee/workspace-forking/lib/copy/copy-workflows.ts

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  S[Selected source resources] --> W[Map workflow folders]
  S --> F[Map file folders]
  S --> T[Map table folders]
  S --> K[Map knowledge-base folders]
  W --> U[Merge folder ID maps]
  F --> U
  T --> U
  K --> U
  U --> P[Place copied resources in target folders]
  U --> R[Rewrite sim:folder references]

_{Reviews (3): Last reviewed commit: "fix(fork): drop the sync-time re-home pa..." | Re-trigger Greptile}

@greptile

@cursor review

Re: the remaining "Dangling parent aliases root folder" finding on copy-workflows.ts (L143-152) — I dug into this rather than waving it off, and I believe it should stay as-is. Three independent reasons:

1. The state it describes isn't reachable through the delete path. It requires an active folder whose parent is soft-deleted. archiveFolderCascade (lib/folders/cascade.ts) stamps the entire descendant subtree in a single UPDATE ... WHERE id IN (folderIds) with one shared timestamp, so a parent folder and its child folders are always soft-deleted together — there's no window between them. (The documented partial-failure window in that file is about child resources walked one at a time, not child folders.) And on a hard delete, folder.parentId is ON DELETE SET NULL, so the child's parentId becomes NULL and it is genuinely root-level — reusing a same-named target root folder is then exactly right, not a mis-placement.

2. The suggested remedy would throw. A "distinct re-rooted copy" cannot exist: folder_workspace_resource_parent_name_active_unique is a partial unique index on (workspace_id, resource_type, coalesce(parent_id, ''), name) WHERE deleted_at IS NULL. Two active root folders with the same name in the same collection are forbidden, so creating a distinct one would raise a unique violation and abort the entire fork/sync transaction — strictly worse than the current behavior.

3. Reuse-by-name is the mapper's deliberate policy, not a quirk of this branch. The same ${mappedParentId ?? ''}::${name} lookup is what makes the ordinary case work (source root Reports maps onto target root Reports instead of duplicating it). The dangling-parent path re-roots first and then applies that same policy consistently.

This is also pre-existing behavior that predates the PR — it shipped for workflow folders and is unchanged here; this PR only parameterizes the mapper by resource_type so files, tables, and knowledge bases stop being flattened to the root. Tightening the reuse rule would change shipped workflow fork placement for a state the delete path does not produce, which is risk without benefit.

Happy to change it if you disagree — but the fix would need to be "re-root the content to the target root (folder_id = NULL)" rather than "create a distinct folder," since the index rules the latter out.

@greptile