v0.5.111: non-polling webhook execs off trigger.dev, gmail subject headers, webhook trigger configs

[icecrasher321]

• fix(gmail): RFC 2047 encode subject headers for non-ASCII characters (fix(gmail): RFC 2047 encode subject headers for non-ASCII characters #3526)
• feat(webhooks): dedup and custom ack configuration (feat(webhooks): dedup and custom ack configuration #3525)
• improvement(webhooks): move non-polling executions off trigger.dev (improvement(webhooks): move non-polling executions off trigger.dev #3527)

[cursor]

PR Summary

Medium Risk
Changes webhook execution routing and idempotency behavior, which can affect delivery semantics and retry/duplication handling across providers. Also tweaks workflow change detection normalization, which could alter when deployments are considered changed.

Overview
Webhooks: Adds new generic webhook trigger options for deduplication (derive an idempotency key from a dot-path in the payload) and custom acknowledgements (custom status code + optional JSON/text body). The webhook processor now strips any incoming x-sim-idempotency-key header, computes its own for generic, and recognizes x-sim-idempotency-key as the highest-priority idempotency key source.

Execution backend routing: Introduces getInlineJobQueue() (Redis→DB) and routes non-polling webhook executions to run inline even when Trigger.dev is enabled, while polling providers continue to use the full job queue when Trigger.dev is active. Polling providers are centralized via POLLING_PROVIDERS/isPollingWebhookProvider and polling triggers are explicitly marked with polling: true.

Other fixes: Gmail message building now RFC 2047-encodes non-ASCII Subject headers (with tests). Workflow comparison normalization now ignores subBlock type changes (test updated), and trigger execution caching returns any existing output (even empty objects).

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

[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:39am

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[greptile-apps]

Greptile Summary

This PR bundles three improvements: non-polling webhooks (generic, Slack, etc.) are moved off Trigger.dev to always execute inline via a new getInlineJobQueue() path; generic webhooks gain deduplication-field configuration and custom ACK response support; and Gmail email subjects are now RFC 2047 encoded to handle non-ASCII characters safely.

Key changes:

• processor.ts: New routing logic — only polling providers (gmail, outlook, rss, imap) use the Trigger.dev queue when it is available; all other webhook providers always go through getInlineJobQueue() (Redis → Database fallback) and execute inline.
• processor.ts: x-sim-idempotency-key is stripped from incoming headers to prevent spoofing, then re-injected from a user-configured dot-path field in the payload, enabling per-field deduplication for generic webhooks.
• processor.ts: Custom ACK response (status code + body) is returned for generic webhooks when responseMode === 'custom'.
• tools/gmail/utils.ts: Adds encodeRfc2047 which Base64-encodes non-ASCII subjects. The current ASCII passthrough regex ([\x00-\x7F]) includes control characters such as CR/LF, which could permit header injection if a subject contains bare line endings.
• trigger-handler.ts: The guard on existingState.output was simplified from checking Object.keys(...).length > 0 to a plain truthy check, changing behaviour when the stored output is an empty object {}.
• triggers/constants.ts: Adds POLLING_PROVIDERS set and isPollingWebhookProvider helper, backed by a new cross-check test against TRIGGER_REGISTRY.
• normalize.ts: Excludes the type field from subblock comparison, eliminating false-positive "workflow changed" detections on type-only subblock changes.

Confidence Score: 3/5

• PR is largely safe but contains a potential email header injection vector and a subtle behavioural change in trigger execution that warrant fixes before merging to production.
• The routing refactor and dedup/custom-ACK features are well-structured and tested. However, the encodeRfc2047 ASCII passthrough allows control characters (CR/LF) through unencoded, creating a potential header injection path in composed Gmail messages. Additionally, the trigger-handler.ts simplification changes the fallback behaviour for trigger blocks with empty outputs in a way that is asymmetric with executeStarterBlock and undocumented. These two issues reduce confidence below a straightforward merge.
• apps/sim/tools/gmail/utils.ts (control-character passthrough in encodeRfc2047) and apps/sim/executor/handlers/trigger/trigger-handler.ts (asymmetric empty-output guard).

Important Files Changed

Filename	Overview
apps/sim/lib/webhooks/processor.ts	Core change: non-polling webhooks now bypass Trigger.dev and always execute inline via getInlineJobQueue(); adds deduplication field injection via x-sim-idempotency-key and custom response body support for generic webhooks. Routing logic has a subtle edge case where polling providers also fall through to inline in non-Trigger.dev environments.
apps/sim/executor/handlers/trigger/trigger-handler.ts	Simplified early-return guard from existingState?.output && Object.keys(existingState.output).length > 0 to existingState?.output, changing behaviour when output is an empty object — now returns {} immediately instead of falling back to starter block output. Inconsistent with the same guard kept in executeStarterBlock.
apps/sim/tools/gmail/utils.ts	Adds encodeRfc2047 to Base64-encode non-ASCII email subjects per RFC 2047. The ASCII passthrough regex [\x00-\x7F] permits control characters (CR/LF) which could enable header injection; should use printable-ASCII range [\x20-\x7E] instead.
apps/sim/triggers/constants.ts	Adds POLLING_PROVIDERS set and isPollingWebhookProvider helper to consolidate provider routing logic. The set is a duplicate of polling: true flags in trigger configs — kept in sync by a new test, but still a manual maintenance point.
apps/sim/lib/core/async-jobs/config.ts	Adds getInlineJobQueue() which always returns a Redis or Database backend, bypassing Trigger.dev. Cache is correctly reset in resetJobQueueCache(). Minor race condition possible on first call under high concurrency, but functionally harmless.
apps/sim/lib/core/idempotency/service.ts	Adds x-sim-idempotency-key as the first header checked in createWebhookIdempotencyKey, giving the user-configured deduplication field highest priority over other provider-specific ID headers.
apps/sim/triggers/generic/webhook.ts	Adds three new trigger subblocks: idempotencyField (deduplication dot-path), responseMode (default/custom dropdown), and conditional responseStatusCode/responseBody fields for custom ACK configuration.
apps/sim/lib/workflows/comparison/normalize.ts	Excludes type from subblock comparison in extractSubBlockRest, so subblock type changes no longer trigger false-positive workflow-changed detections. Matching test updated accordingly.
apps/sim/triggers/gmail/poller.ts	Adds polling: true to the Gmail trigger config to formally mark it as poll-based. Same minimal change applied to imap, outlook, and rss pollers.
apps/sim/tools/gmail/utils.test.ts	New test file covering encodeRfc2047: ASCII passthrough, empty string, emoji encoding, round-trip for several non-ASCII scripts, and double-encode prevention. Good coverage for the happy path.
apps/sim/triggers/constants.test.ts	New test that cross-checks POLLING_PROVIDERS against TRIGGER_REGISTRY, ensuring the two sources of truth stay in sync in both directions.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Incoming Webhook POST] --> B[queueWebhookExecution]
B --> C{Strip x-sim-idempotency-key\nfrom headers}
C --> D{provider == 'generic'\n& idempotencyField set?}
D -- Yes --> E[Resolve dot-path in body\nInject x-sim-idempotency-key]
D -- No --> F[Build payload]
E --> F
F --> G{isPollingWebhookProvider?}
G -- Yes --> H{shouldExecuteInline?\ni.e. NOT Trigger.dev}
H -- No\nTrigger.dev available --> I[getJobQueue\nEnqueue via Trigger.dev]
H -- Yes\nRedis or DB mode --> J[getInlineJobQueue\nEnqueue + fire inline]
G -- No\nnon-polling webhook --> J
I --> K[Response]
J --> K
K --> L{provider-specific\nresponse?}
L -- microsoft-teams --> M[202 / teams message]
L -- slack --> N[200 empty]
L -- twilio_voice --> O[TwiML XML]
L -- generic + custom responseMode --> P[Custom status + body]
L -- default --> Q[200 Webhook processed]

Loading

Comments Outside Diff (1)

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

   Polling providers fall through to inline in non-Trigger.dev environments

   The condition if (isPolling && !shouldExecuteInline()) means that when using a Redis or Database backend (shouldExecuteInline() === true), polling providers (gmail, outlook, rss, imap) fall into the else branch and are executed inline just like non-polling webhooks.

   While this preserves the pre-existing behaviour for those environments, the log message in the else branch says "Executing ... webhook ... inline" for all cases — including polling providers on Redis/DB. If the intent is that polling providers should always use Trigger.dev (when available) and only fall back to inline when Trigger.dev isn't configured, the condition should be isPolling alone (without !shouldExecuteInline()). The current phrasing could cause silent routing surprises when Trigger.dev is later removed from an environment that previously used it for polling.

_{Last reviewed commit: 68d207d}