chore(worker): correct stall recovery comments

Author: viethungpv91

apps/worker/src/env.ts

@@ -26,7 +26,8 @@ export const env = createEnv({
     // otherwise BullMQ would treat the job as stalled and reprocess it (double
     // send). Validated so a bad value can't become NaN (= wait forever). Since
     // the coexist split (heavy worker), this max (9 min) is the ONLY reason the
-    // integration worker's lockDuration/stalledInterval stay at 10 min — see
+    // integration worker's lockDuration stays at 10 min (its stalledInterval
+    // reverted to the BullMQ default) — see
     // `apps/worker/src/integration/worker.ts`.
     CHAT_JOB_WAIT_TIMEOUT_MS: z.coerce
       .number()

apps/worker/src/integration/worker.ts

@@ -367,10 +367,12 @@ async function startIntegrationWorker() {
       // the max wait to tighten this lock (see plan §7, out of scope here).
       lockDuration: 10 * 60 * 1000,
       // No stalledInterval override: with coexist gone there are no
-      // long-running jobs here, so the BullMQ default (30s) applies — a
-      // crashed worker's jobs are re-picked in seconds instead of minutes.
-      // Live workers auto-renew their locks, so the frequent check cannot
-      // false-positive an in-progress job.
+      // long-running jobs here, so the BullMQ default (30s) applies. A
+      // crashed worker's job is reclaimed once its lock EXPIRES and the next
+      // scan runs — ~10–10.5 min after the crash (lock expiry + ≤30s scan),
+      // down from ~10–20 min with the old 10-min scan interval. Live workers
+      // auto-renew their locks (including through awaitChatJob waits), so the
+      // frequent check cannot false-positive an in-progress job.
       maxStalledCount: 1,
     },
   )