fix(logs): saturate the cancelled-run duration at the column ceiling

The column is `integer`, so an untimed run cancelled after roughly
twenty-five days overflowed the cast. That cost more than the duration it
was recording: the direct write is caught and logged, so the row would
have stayed `running` with no end timestamp at all, and the
workflow-group write would have failed its transaction and taken the
whole cancellation with it.

Saturating keeps the terminal write. A duration wrong in its last digits
is a smaller lie than a run that never ended.

Author: waleedlatif1

apps/sim/lib/logs/execution/duration.test.ts

@@ -37,7 +37,7 @@ describe('elapsedDurationMsSql', () => {
     const { sql, params } = render(new Date('2026-08-13T12:00:05.000Z'))
 
     expect(sql).toContain('::timestamp')
-    expect(params).toEqual(['2026-08-13T12:00:05.000Z'])
+    expect(params).toContain('2026-08-13T12:00:05.000Z')
     expect(params.some((param) => Array.isArray(param))).toBe(false)
   })
 
@@ -49,4 +49,17 @@ describe('elapsedDurationMsSql', () => {
     expect(sql).toContain('ROUND(')
     expect(sql).toContain('::integer')
   })
+
+  /**
+   * An untimed run cancelled after ~24.8 days exceeds `integer`. Without the
+   * ceiling the cast raises, and the terminal write is lost entirely — the row
+   * stays `running` with no end timestamp, which is worse than a saturated
+   * duration.
+   */
+  it('saturates at the column ceiling instead of overflowing the cast', () => {
+    const { sql, params } = render(new Date('2026-08-13T12:00:05.000Z'))
+
+    expect(sql).toContain('LEAST(')
+    expect(params).toContain(2_147_483_647)
+  })
 })

apps/sim/lib/logs/execution/duration.ts

@@ -19,7 +19,18 @@ import { type SQL, sql } from 'drizzle-orm'
  *
  * Floored at 1ms to match `completeWorkflowExecution`, so a cancellation that
  * lands inside the same millisecond as the start still records that it ran.
+ *
+ * Saturated at the column's own ceiling rather than left to overflow. The
+ * column is `integer`, so an untimed run cancelled after ~24.8 days would
+ * otherwise raise `numeric_value_out_of_range` — which costs more than the
+ * duration it was recording: the direct write is caught and logged, leaving
+ * the row `running` with no end timestamp at all, and the workflow-group write
+ * fails its transaction and takes the whole cancellation with it. A saturated
+ * duration is wrong in the last digit; a failed terminal write is wrong about
+ * whether the run ended.
  */
+const INT4_MAX_MS = 2_147_483_647
+
 export function elapsedDurationMsSql(endedAt: Date): SQL<number> {
-  return sql<number>`GREATEST(1, ROUND(EXTRACT(EPOCH FROM (${endedAt.toISOString()}::timestamp - ${workflowExecutionLogs.startedAt})) * 1000))::integer`
+  return sql<number>`LEAST(${INT4_MAX_MS}, GREATEST(1, ROUND(EXTRACT(EPOCH FROM (${endedAt.toISOString()}::timestamp - ${workflowExecutionLogs.startedAt})) * 1000)))::integer`
 }