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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 16, 2026 0:28am

PR Summary

Medium Risk
Moderate risk because it changes idempotency behavior for webhookIdempotency/pollingIdempotency (duplicates may now return undefined instead of a cached body) and enforces hard trimming of stream replay history, which could affect consumers relying on older events.

Overview
Reduces Redis memory pressure by making idempotency storage optionally omit operation result bodies via a new storeResultBody flag (default true), and configuring webhookIdempotency + pollingIdempotency to persist only a lightweight completion marker.

Also caps mothership stream event history by trimming the Redis ZSET to eventLimit on every appendEvents call (ZREMRANGEBYRANK), with the buffer test updated to assert trimming happens on each append.

^{Reviewed by Cursor Bugbot for commit 78b3d96. Configure here.}

Greptile Summary

Two targeted Redis memory fixes following a 2026-05-15 OOM incident: the mothership stream buffer now enforces its eventLimit cap on every append (previously dead code let ZSETs grow unbounded until the 1-hour TTL fired), and the webhook/polling idempotency services now store only a { success, status } marker instead of the full response body.

• buffer.ts: A single ZREMRANGEBYRANK key 0 -(eventLimit+1) is inserted into the appendEvents pipeline immediately after ZADD, trimming the oldest entries so the ZSET is capped at eventLimit (default 5,000) on every write. The test pins the exact stop argument (-5_001) to guard the off-by-one boundary.
• service.ts: New storeResultBody flag (defaults true to preserve Stripe-style callers) is set to false on webhookIdempotency and pollingIdempotency; duplicate calls still short-circuit but the cached value returned on the completed/in-progress paths will be undefined as T for these two instances.

Confidence Score: 4/5

Safe to merge for the buffer cap change; the idempotency body-stripping is intentionally lossy for webhook and polling paths where callers don't read the return value, but that assumption isn't enforced by the type system.

The pollingIdempotency change is the one place worth a second look: duplicate polling calls that arrive while the first is in-progress or after it completes will receive undefined as T from executeWithIdempotency. TypeScript's cast suppresses the type error, so any polling handler that reads the resolved value will silently receive undefined on the duplicate path without a compile-time signal.

apps/sim/lib/core/idempotency/service.ts — specifically any callers of pollingIdempotency.executeWithIdempotency that read the resolved value

Important Files Changed

_{Reviews (2): Last reviewed commit: "test(buffer): pin exact ZREMRANGEBYRANK ..." | Re-trigger Greptile}

Re Greptile's outside-diff note on waitForResult returning undefined as T when storeResultBody: false:

Audited all callers and this is safe:

• All pollingIdempotency callers (gmail.ts, outlook.ts, imap.ts, rss.ts, google-drive.ts, google-calendar.ts, google-sheets.ts) invoke as bare await pollingIdempotency.executeWithIdempotency(...) and discard the return value.
• webhookIdempotency caller (background/webhook-execution.ts:268) returns the value to jobQueue.completeJob(jobId, output). A duplicate-delivery returning undefined here just stores undefined as the BullMQ job output, which is benign — the original delivery already executed the workflow and recorded its real output.

The contract is also documented on the storeResultBody field: "Duplicate calls still short-circuit but resolve to undefined". No code change needed.

@greptile

@cursor review