improvement(webhooks): move non-polling executions off trigger.dev

[icecrasher321]

Summary

Move non-polling executions off trigger.dev to beat cold start times

Type of Change

• Other: Performance

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 12, 2026 0:06am

[cursor]

PR Summary

Medium Risk
Changes webhook execution routing and job-queue backend selection, which can affect delivery semantics and error handling for incoming webhooks. Risk is limited by keeping polling providers on the existing queued path and adding tests to keep provider classification consistent.

Overview
Webhook executions are now routed based on whether the provider is poll-based. Polling providers continue to enqueue via the full job queue when trigger-dev is active, while non-polling providers bypass Trigger.dev and run inline using a new Redis/DB-backed getInlineJobQueue() backend.

Adds a centralized POLLING_PROVIDERS/isPollingWebhookProvider() helper (plus TriggerConfig.polling flags on poller triggers) and uses it for both credential-set path uniqueness and execution routing, with a new test ensuring the polling-provider set stays in sync with the trigger registry.

^{Written by Cursor Bugbot for commit f20dafa. Configure here.}

[greptile-apps]

Greptile Summary

This PR improves webhook performance by routing non-polling webhook providers (everything except gmail, outlook, rss, and imap) away from Trigger.dev and directly into an inline Redis/DB execution path, eliminating Trigger.dev cold-start latency for the majority of webhook events. It also introduces a polling?: boolean field on TriggerConfig and a POLLING_PROVIDERS set + isPollingWebhookProvider() helper to centralise the routing decision.

Key changes:

• processor.ts: queueWebhookExecution now checks isPollingWebhookProvider first; non-polling providers always use getInlineJobQueue() and execute fire-and-forget inline, even when Trigger.dev is the configured backend.
• config.ts: New getInlineJobQueue() function returns a Redis-or-DB backend, bypassing Trigger.dev entirely, with its own cache slot (cachedInlineBackend).
• constants.ts: Introduces POLLING_PROVIDERS as a hardcoded Set that mirrors the new polling: true field on TriggerConfig — this is a dual source of truth and must be kept manually in sync when new polling triggers are added.
• types.ts / poller files: polling?: boolean is added to the TriggerConfig interface and set to true on all four polling triggers.

Confidence Score: 4/5

• Safe to merge with the understanding that the POLLING_PROVIDERS set and TriggerConfig.polling field must be kept in sync manually going forward.
• The core routing logic is sound and all four existing polling providers are correctly identified in both places. The main risk is a maintainability gap — POLLING_PROVIDERS is a hardcoded set that duplicates the polling: true flag on TriggerConfig, with no compile-time or runtime guard to catch divergence when new polling providers are added. The secondary concern is that the condition isPolling && !shouldExecuteInline() means polling providers in Redis/DB-only environments silently use cachedInlineBackend rather than cachedBackend, creating two separate queue instances pointing at the same storage — functionally harmless but worth being aware of.
• Pay close attention to apps/sim/triggers/constants.ts (POLLING_PROVIDERS set) and apps/sim/lib/webhooks/processor.ts (routing condition).

Important Files Changed

Filename	Overview
apps/sim/lib/webhooks/processor.ts	Core routing logic changed: non-polling webhooks now always use getInlineJobQueue() and execute fire-and-forget, bypassing Trigger.dev. Logic is mostly correct but the condition causes polling providers in non-Trigger.dev environments to use a separate cache instance from getJobQueue().
apps/sim/triggers/constants.ts	Introduces POLLING_PROVIDERS set and isPollingWebhookProvider() helper. The hardcoded set is a dual source of truth with TriggerConfig.polling — no enforcement that they stay in sync when new polling providers are added.
apps/sim/lib/core/async-jobs/config.ts	Adds getInlineJobQueue() which always returns a Redis or DB backend, bypassing Trigger.dev. Cache is properly reset in resetJobQueueCache(). Log message is not informative (previously flagged).
apps/sim/lib/webhooks/utils.server.ts	Replaces inline pollingProviders array with isPollingWebhookProvider() — clean refactor with no logic change.
apps/sim/app/api/webhooks/route.ts	Minor simplification: replaces pollingProviders.includes(provider) with direct equality checks for needsConfiguration. Intentionally does not use isPollingWebhookProvider since this checks OAuth configuration, not polling behavior.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Incoming Webhook Request] --> B[queueWebhookExecution]
B --> C{isPollingWebhookProvider?}
C -- "Yes (gmail/outlook/rss/imap)" --> D{shouldExecuteInline?\ni.e. Trigger.dev disabled?}
C -- "No (all other providers)" --> G
D -- "No (Trigger.dev active)" --> E[getJobQueue → Trigger.dev\nenqueue only\nTrigger.dev executes async]
D -- "Yes (Redis/DB mode)" --> G
G[getInlineJobQueue\nRedis or DB backend\nenqueue + fire-and-forget inline execution]
E --> H[Return HTTP response]
G --> H

Loading

Comments Outside Diff (1)

1. apps/sim/lib/webhooks/processor.ts, line 1122-1162 (link)

   Polling providers silently fall through to inline execution when Trigger.dev is active

   The condition on line 1122 is isPolling && !shouldExecuteInline(). When isPolling=true but shouldExecuteInline()=true (i.e. Trigger.dev is not configured — Redis or DB mode), the else branch is taken and the job is enqueued via getInlineJobQueue() and executed inline. This is functionally correct, but it means that in a non-Trigger.dev environment, polling providers like Gmail and Outlook silently bypass getJobQueue() (which was previously used for all providers) and go through a separate cachedInlineBackend instance instead.

   Both cache entries resolve to the same underlying backend (Redis or DB) in this environment, so there is no data loss risk. However, two separate queue object instances are now managing jobs against the same storage. It would be clearer to have polling providers in non-Trigger.dev environments explicitly use getJobQueue() (which they previously did), and only use getInlineJobQueue() for the explicit non-polling bypass path:

   if(isPolling){constjobQueue=awaitgetJobQueue()// Trigger.dev or Redis/DBconstjobId=awaitjobQueue.enqueue(...)if(shouldExecuteInline()){void(async()=>{/* inline execution */})()}}else{constjobQueue=awaitgetInlineJobQueue()// Always Redis/DB, bypass Trigger.devconstjobId=awaitjobQueue.enqueue(...)void(async()=>{/* inline execution */})()}

   This makes the routing intent explicit: polling providers always use the configured job queue (Trigger.dev when available), non-polling providers always use the inline queue to bypass Trigger.dev.

_{Last reviewed commit: c5abed3}

[icecrasher321]

bugbot run

[icecrasher321]

@greptile

[icecrasher321]

bugbot run

[icecrasher321]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR