docs(deploy): name the tripwire as the mechanism, not pool starvation

The previous commit attributed the 500 to pool starvation under concurrency.
That was wrong. `packages/db/tx-tripwire.ts` marks the async context for the
duration of a transaction callback and reports any query issued on the global
pool inside it — throwing outside production, warning in production. So the
failure was deterministic in dev, not load-dependent, which is why it reported
against the authz lookup rather than anything the caller wrote.

Saturation deadlock is what the tripwire exists to PREVENT, not what happened.
Recording the real mechanism, since the wrong one would send the next reader
looking for a concurrency bug.

Also drops a comment claiming a transaction connection "cannot serve concurrent
statements". `loadWorkflowDeploymentSnapshot` issues two tx-handle reads under
`Promise.all` and has always worked, so the claim is false; the sequential reads
stay because they are clearer, not because concurrency is unsafe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: icecrasher321

apps/sim/lib/workflows/deployment-status.ts

@@ -25,12 +25,15 @@ export async function checkNeedsRedeployment(workflowId: string): Promise<boolea
     await tx.execute(sql`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ`)
     /*
      * `workspaceId` is selected here, in this transaction, rather than left for
-     * `materializeDeploymentState` to look up. It resolves an absent one through
-     * `getActiveWorkflowContext`, which runs on the global pool — a second
-     * connection checkout while this transaction already holds one. Under any
-     * concurrency (this endpoint is polled, and refetches on window focus) that
-     * starves the pool and fails the nested read, surfacing as a 500 on
-     * `/api/workflows/[id]/deploy`. A transaction must not await a checkout.
+     * `materializeDeploymentState` to look up: resolving an absent one goes
+     * through `getActiveWorkflowContext`, which queries the global pool, and
+     * this callback already holds a pooled connection.
+     *
+     * `packages/db/tx-tripwire.ts` detects exactly that and throws outside
+     * production, so it did not degrade quietly — it 500'd every
+     * `/api/workflows/[id]/deploy` in dev, reported against the authz lookup
+     * rather than anything this function wrote. Hoisting the read into the
+     * transaction is the tripwire's own first remedy.
      */
     const [active] = await tx
       .select({
@@ -52,10 +55,6 @@ export async function checkNeedsRedeployment(workflowId: string): Promise<boolea
     /* The inner join guarantees a workspace row; a null id means unusable data. */
     if (!active?.state || !active.workspaceId) return false
 
-    /*
-     * Sequential, not `Promise.all`: both reads share the transaction's single
-     * connection, which cannot serve concurrent statements.
-     */
     const currentState = await loadWorkflowDeploymentSnapshot(workflowId, tx)
     if (!currentState) return false
 

apps/sim/lib/workflows/persistence/utils.ts

@@ -175,11 +175,11 @@ interface DeploymentStateRow {
  */
 /**
  * `workspaceId` is required rather than resolved here on purpose. Resolving it
- * means `getActiveWorkflowContext`, which runs on the global pool — and this
- * function is called from inside a REPEATABLE READ transaction by
- * `checkNeedsRedeployment`, where a second connection checkout while holding one
- * starves the pool under concurrency and fails the nested read. Taking it as an
- * argument makes that impossible instead of merely avoided.
+ * means `getActiveWorkflowContext`, which queries the global pool, and
+ * `checkNeedsRedeployment` calls this from inside a REPEATABLE READ transaction
+ * that already holds a pooled connection — the nested checkout
+ * `packages/db/tx-tripwire.ts` exists to catch. Taking the id as an argument
+ * makes the violation unrepresentable rather than merely avoided.
  */
 export async function materializeDeploymentState(
   workflowId: string,