fix(table): cut dispatcher cold-start by lazy-loading heavy import chains

The trigger.dev table-run-dispatcher spent ~6s in module init before its
first batchTriggerAndWait — it imports lib/table/service for getTableById,
which eagerly imported lib/table/trigger → @/lib/webhooks/processor →
webhook-execution + executor, dragging the entire workflow-execution stack
into the dispatcher container even though it never fires a trigger.

- trigger.ts lazy-imports the webhook processor + polling utils inside
  fireTableTrigger (the only consumer), so importing service no longer pulls
  the executor.
- buildEnqueueItems only imports the cell job (for the inline `runner`) on the
  database backend; the trigger.dev backend triggers by task id and ignores
  runner.

Author: TheodoreSpeaks

apps/sim/lib/table/trigger.ts

@@ -9,8 +9,6 @@
 import { createLogger } from '@sim/logger'
 import { generateShortId } from '@sim/utils/id'
 import type { RowData, TableRow, TableSchema } from '@/lib/table/types'
-import { fetchActiveWebhooks } from '@/lib/webhooks/polling/utils'
-import { processPolledWebhookEvent } from '@/lib/webhooks/processor'
 
 const logger = createLogger('TableTrigger')
 
@@ -57,6 +55,11 @@ export async function fireTableTrigger(
   requestId: string
 ): Promise<void> {
   try {
+    // Lazy-imported: `@/lib/webhooks/processor` transitively pulls in the
+    // workflow executor + blocks stack. Importing it eagerly would force every
+    // consumer of `lib/table/service` (e.g. the dispatcher, which only needs
+    // `getTableById`) to pay that cold-start even when no trigger ever fires.
+    const { fetchActiveWebhooks } = await import('@/lib/webhooks/polling/utils')
     const webhooks = await fetchActiveWebhooks('table')
     if (webhooks.length === 0) return
 
@@ -74,6 +77,8 @@ export async function fireTableTrigger(
 
     if (matching.length === 0) return
 
+    const { processPolledWebhookEvent } = await import('@/lib/webhooks/processor')
+
     logger.info(
       `[${requestId}] Firing ${matching.length} trigger(s) for ${rows.length} ${eventType} event(s) in table ${tableId}`
     )

apps/sim/lib/table/workflow-columns.ts

@@ -203,11 +203,20 @@ export function buildPendingRuns(
 /** Build the per-cell `{payload, options}` items for `queue.batchEnqueue` /
  *  `queue.batchEnqueueAndWait`. Hydrates trigger.dev tags, concurrency keys,
  *  the inline runner, and the cancel key the inline backend uses to map a
- *  Stop click to the in-flight cell's AbortController. */
+ *  Stop click to the in-flight cell's AbortController.
+ *
+ *  The `runner` is only consumed by the database (inline) backend — the
+ *  trigger.dev backend triggers by task id. Importing the cell job pulls in
+ *  the entire executor + blocks stack, so on trigger.dev we skip the import
+ *  entirely: the dispatcher container would otherwise pay a multi-second
+ *  cold-start loading code it never runs (the cell runs in its own container). */
 export async function buildEnqueueItems(
   pendingRuns: WorkflowGroupCellPayload[]
 ): Promise<Array<{ payload: WorkflowGroupCellPayload; options: EnqueueOptions }>> {
-  const { executeWorkflowGroupCellJob } = await import('@/background/workflow-column-execution')
+  const runner = isTriggerDevEnabled
+    ? undefined
+    : ((await import('@/background/workflow-column-execution'))
+        .executeWorkflowGroupCellJob as EnqueueOptions['runner'])
   return pendingRuns.map((runOpts) => ({
     payload: runOpts,
     options: {
@@ -225,7 +234,7 @@ export async function buildEnqueueItems(
       concurrencyKey: runOpts.tableId,
       concurrencyLimit: TABLE_CONCURRENCY_LIMIT,
       tags: cellTagsFor(runOpts),
-      runner: executeWorkflowGroupCellJob as EnqueueOptions['runner'],
+      ...(runner ? { runner } : {}),
       cancelKey: cellCancelKey(runOpts.tableId, runOpts.rowId, runOpts.groupId),
     },
   }))