refactor(trigger): derive the fork ceiling from STALE_ACTIVE_MS and trim sizing comments

Author: waleedlatif1

apps/sim/background/cleanup-file-versions.ts

@@ -189,9 +189,8 @@ export async function runCleanupFileVersions(payload: CleanupJobPayload): Promis
 export const cleanupFileVersionsTask = task({
   id: 'cleanup-file-versions',
   /**
-   * Sized from production telemetry: peak RSS 219 MB across ~15,600 runs, so
-   * `small-2x` (1 GB) holds over four times the worst case. Each pass works in
-   * bounded batches of version rows, so the peak does not grow with backlog.
+   * Each pass works in bounded batches of version rows, so peak memory stays well under
+   * `small-2x` (1 GB) and does not grow with backlog.
    */
   machine: 'small-2x',
   maxDuration: 600,

apps/sim/background/cleanup-stale-executions.ts

@@ -50,18 +50,15 @@ const EXECUTION_DEADLINE_ERROR = getTimeoutErrorMessage()
 /**
  * Table jobs run as detached workers with progress heartbeats, independently of workflow timeout
  * policy. A running job is treated as dead once its last progress write (`updatedAt`) is older
- * than this. It measures the gap since the last heartbeat, not run length, so it does not track
- * any task's `maxDuration`; it only has to exceed the longest stretch a live worker goes without
- * writing progress.
+ * than this, so it must exceed the longest gap between a live worker's heartbeats.
  */
 const TABLE_JOB_STALE_THRESHOLD_MINUTES = 95
 /** Terminal table-jobs older than this are pruned; only the latest job per table is ever read. */
 const TABLE_JOB_RETENTION_HOURS = 24
 /**
  * A table run dispatch whose holder has not made progress for this long is
- * treated as dead. Same shape and window as the table-job threshold above,
- * measured from the dispatcher's own per-window heartbeat rather than from when
- * the run was requested, so it is independent of the task's `maxDuration`.
+ * treated as dead. Same rule as the table-job threshold above, measured from the
+ * dispatcher's own per-window heartbeat rather than from when the run was requested.
  */
 const TABLE_DISPATCH_STALE_THRESHOLD_MINUTES = 95
 /** Per-run ceiling on reaped dispatches, so one tick cannot fan out unbounded SSE. */

apps/sim/background/fork-content-copy.ts

@@ -1,4 +1,5 @@
 import { task } from '@trigger.dev/sdk'
+import { STALE_ACTIVE_MS } from '@/ee/workspace-forking/lib/background-work/store'
 import {
   type ForkContentCopyPayload,
   runForkContentCopy,
@@ -21,13 +22,11 @@ export const forkContentCopyTask = task({
   id: 'fork-content-copy',
   machine: 'large-2x',
   /**
-   * Inside `STALE_ACTIVE_MS` (30 minutes, in the background-work store), after
-   * which the outbox cron marks the fork's status row failed. A run outliving
-   * that would keep copying under a status that already says it failed; the
-   * remaining five minutes absorb queue wait, since the row starts its clock at
-   * fork time.
+   * Ends inside {@link STALE_ACTIVE_MS}, after which the outbox cron marks the fork's status
+   * row failed, so a run never keeps copying under a status that already says it failed. The
+   * five-minute margin absorbs queue wait, since the row's clock starts at fork time.
    */
-  maxDuration: 1500,
+  maxDuration: STALE_ACTIVE_MS / 1000 - 5 * 60,
   retry: { maxAttempts: 1 },
   queue: {
     name: 'fork-content-copy',

apps/sim/ee/workspace-forking/lib/background-work/store.ts

@@ -53,7 +53,7 @@ const BACKGROUND_WORK_PAGE_SIZE_MAX = 100
  * sweeps these via {@link reapStaleBackgroundWork}, marking them `failed` so the UI
  * surfaces the failure instead of spinning forever.
  */
-const STALE_ACTIVE_MS = 30 * 60 * 1000
+export const STALE_ACTIVE_MS = 30 * 60 * 1000
 
 /** Terminal rows older than this are pruned by the cron so the audit trail stays bounded. */
 const RETENTION_MS = 30 * 24 * 60 * 60 * 1000