refactor(trigger): tighten the comments on the worker dispatch fix

Author: waleedlatif1

apps/sim/lib/knowledge/documents/service.ts

@@ -756,11 +756,9 @@ async function dispatchViaBatchTrigger(
   }
 
   /**
-   * Only a total dispatch failure raises, so a chunk that failed on its own used
-   * to leave its documents sitting at `pending` with nothing recording why —
-   * invisible until the stuck-document sweep happened to pick them up, and never
-   * if they aged out of its window first. Running them here costs the caller time
-   * it hoped to hand to the queue, which is the point: the work still happens.
+   * Only a total dispatch failure raises, so a chunk failing alone would leave its
+   * documents at `pending` with nothing recording why. Processing them here is
+   * slower than the queue but does not drop the work.
    */
   if (undispatched.length > 0) {
     logger.warn(

apps/sim/trigger.config.ts

@@ -76,17 +76,11 @@ export default defineConfig({
       syncEnvVars(() => [
         { name: 'DB_APP_NAME', value: 'sim-trigger' },
         /**
-         * Workers run Trigger.dev by definition, but the flag that says so is
-         * read from the environment and was only ever set on the app container.
-         * `isTriggerAvailable()` therefore returned false inside every worker, so
-         * anything a task dispatched — document processing above all — silently
-         * took the in-process path instead of the queue it was written for. A
-         * connector sync ended up chunking and embedding thousands of documents
-         * itself, five at a time, and running until it hit its max duration.
-         *
-         * Safe to assert here because the check also requires TRIGGER_SECRET_KEY,
-         * which only the Trigger.dev runtime provides: where dispatching is not
-         * actually possible this stays false and nothing changes.
+         * Workers run Trigger.dev by definition, but the flag saying so was only
+         * set on the app container, so `isTriggerAvailable()` was false in every
+         * task run and dispatched work silently took the in-process fallback.
+         * Ineffective where dispatching is impossible: the check also requires
+         * TRIGGER_SECRET_KEY, which only the Trigger.dev runtime provides.
          */
         { name: 'TRIGGER_DEV_ENABLED', value: 'TRUE' },
       ]),