fix(folders): run reorder lock checks on the reorder transaction

[waleedlatif1]

Summary

• PUT /api/folders/reorder ran assertFolderMutable inside its withTransactionRetry callback, but the lock walk queried the global pool. Each check took a second connection while the transaction held one, which can deadlock the pool at saturation (the @sim/db transaction tripwire flags exactly this)
• assertFolderMutable now accepts an optional executor (the same Pick<typeof db, 'select'> = db shape resolveEffectiveWorkspacePermission uses). The reorder route passes its tx, so the ancestry walk reads on the held connection
• The checks stay inside the transaction instead of being hoisted out, so they still run under the per-workspace folder-tree advisory lock that updateFolder (lock toggles) also takes
• No other caller of assertFolderMutable / assertWorkflowMutable runs inside a transaction. They all check before opening one, and the default executor leaves them unchanged
• Why tests missed it: the route's unit test mocks @sim/db globally, so the real pool instrumentation never ran. The new integration test runs the route against real Postgres with the tripwire in throw mode. All 3 cases fail with 500 before the fix and pass after

Type of Change

• Bug fix

Testing

New app/api/folders/reorder/route.integration.ts covers three cases against real Postgres (tripwire throw): reparent + reorder of unlocked folders, a folder that inherits its ancestor's lock (423), and a locked destination (423). I confirmed it fails on the pre-fix code and passes with the fix.

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
docs	Skipped		Oct 14, 2026 11:31pm UTC

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; folder lock checks now use the reorder transaction without changing existing callers.

Summary

Folder reorder now checks folder locks using the connection its transaction already holds.

• Folder reorder checks locks through its existing transaction.

Diagram

sequenceDiagram
  participant Route as Folder reorder
  participant Tx as Transaction
  participant Check as assertFolderMutable
  Route->>Tx: Acquire folder-tree lock
  Route->>Check: Check source and destination with tx
  loop Each ancestor
    Check->>Tx: Read folder lock and parent
  end
  alt A folder is locked
    Check-->>Route: Throw FolderLockedError
    Route->>Tx: Roll back
  else All folders are unlocked
    Route->>Tx: Update folders and commit
  end

Loading

_{Reviews (1) · Last reviewed commit: "fix(folders): run reorder lock checks on..." · Reviewed by Greptile}