fix(trigger): let workers see that Trigger.dev is available

[waleedlatif1]

Problem

isTriggerAvailable() is Boolean(env.TRIGGER_SECRET_KEY) && isTriggerDevEnabled, and isTriggerDevEnabled reads TRIGGER_DEV_ENABLED. That variable is set on the app container but not in the Trigger.dev environment, so the check is false inside every task run — and work a task dispatches silently takes the in-process fallback instead of the queue it was written for.

Runtime	TRIGGER_DEV_ENABLED	isTriggerAvailable()
App container	TRUE	true — dispatches to the queue
Trigger.dev worker	absent	false — dispatchInProcess

Document processing is where this surfaced. A connector sync chunks and embeds its own documents at IN_PROCESS_DISPATCH_CONCURRENCY = 5 instead of handing them to knowledge-process-document, so that task's queue concurrency limit, machine, retry policy and duration budget all sit unused, and a sync with thousands of documents runs until it hits its own max duration.

Evidence, three independent ways:

1. A connector sync ran the full hour and hit MAX_DURATION_EXCEEDED.
2. Its trace contains "Document dispatch failed" — a string that appears in exactly one place in the codebase, the dispatchInProcess catch block.
3. knowledge-process-document has zero runs for that knowledge base over two days, despite thousands of documents being processed.

The flag is read in 17 files, so the same silent downgrade applies to any dispatching path reachable from a task run, table backfills and imports among them.

Change

Assert the flag for workers via the syncEnvVars extension that already runs there for DB_APP_NAME. Putting it in trigger.config.ts keeps it version-controlled and reviewable rather than being dashboard state that can drift out of agreement with the app again.

This is fail-safe. The availability check still requires TRIGGER_SECRET_KEY, which only the Trigger.dev runtime provides. Anywhere dispatching is not actually possible, the flag stays ineffective and behaviour is unchanged — the change cannot enable dispatch in an environment that cannot dispatch.

Dispatch failure is also made recoverable. Only a total failure raised before, so a single failed batch left its documents at pending with nothing recording why — invisible until the stuck-document sweep happened to reach them, and never if they aged out of its 7-day window first. Those are now processed in-process instead: it costs the caller the time it hoped to hand to the queue, but the work is not dropped. That path was unreachable from a worker until this change made dispatching happen there, which is why it belongs with it.

Risk and how to verify

This changes where document processing executes for every connector sync, so it is worth watching rather than assuming:

• Expected after deploy: knowledge-process-document runs appear for connector-synced knowledge bases, where there are currently none; connector sync runs get much shorter.
• If dispatching turns out not to work from a worker, the flag stays false and nothing changes — or, if it half-works, the guard above processes the remainder in-process rather than dropping it.
• Worth confirming on staging first, since it also affects the table paths that gate on the same flag.

Also here

A comment trim, carried in a second commit rather than its own PR. Both this change's TSDoc and the quota classification's from #6868 explained the incident that motivated the code rather than the code itself — narrative that stops being true as the system moves and misleads instead. Each is cut back to the reason a reader needs; no behaviour change.

Verification

• 632 embedding and knowledge tests pass; 29/29 audits; type-check clean

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 19, 2026 10:56pm

[cursor]

PR Summary

Medium Risk
Shifts where connector sync and other task-originated dispatches run (queue vs in-process) across knowledge and table paths gated on the same flag; mitigated by still requiring TRIGGER_SECRET_KEY and by in-process fallback when enqueue fails.

Overview
Workers previously could not see that Trigger.dev was available because TRIGGER_DEV_ENABLED was only set on the app container. trigger.config.ts now syncs that flag into the Trigger.dev worker environment (alongside DB_APP_NAME), so isTriggerAvailable() is true inside task runs when TRIGGER_SECRET_KEY is present. Work dispatched from workers—especially knowledge document processing during connector syncs—should go to knowledge-process-document on the queue instead of silently falling back to in-process chunking and embedding.

dispatchViaBatchTrigger in the knowledge documents service now collects payloads from failed batchTrigger chunks and runs them via dispatchInProcess instead of leaving those documents stuck at pending with no recorded failure.

^{Reviewed by Cursor Bugbot for commit 3868baa. Configure here.}

[greptile-apps]

Greptile Summary

This PR enables Trigger.dev availability checks inside Trigger.dev workers and recovers partially failed document enqueues by processing those documents in-process.

• Synchronizes TRIGGER_DEV_ENABLED=TRUE into worker environments.
• Collects document batches that fail to enqueue and runs them through the existing bounded in-process processor.
• Preserves queued processing for successful batches while preventing failed batches from remaining silently pending.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issue identified.

The worker flag parses as intended, queued batches retain their existing behavior, and failed batches use the existing per-document in-process path with bounded concurrency and isolated error handling.

Important Files Changed

Filename	Overview
apps/sim/lib/knowledge/documents/service.ts	Adds bounded in-process recovery for document chunks whose Trigger.dev batch enqueue throws; no actionable defect was established.
apps/sim/trigger.config.ts	Synchronizes the existing Trigger.dev enablement flag into worker environments so nested dispatch paths use the queue.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Sync[Connector sync worker] --> Available{Trigger.dev available?}
  Available -- No --> Local[Process documents in-process]
  Available -- Yes --> Batch[Enqueue document batches]
  Batch --> Success[Trigger.dev document workers]
  Batch -->|Batch enqueue fails| Recover[Collect undispatched documents]
  Recover --> Local
  Success --> Process[Parse, chunk, embed, and persist]
  Local --> Process

Loading

_{Reviews (1): Last reviewed commit: "fix(trigger): let workers see that Trigg..." | Re-trigger Greptile}