fix(redis): stop a slow handshake from failing as a command timeout

[waleedlatif1]

Summary

• commandTimeout was set below connectTimeout. ioredis arms that timer in sendCommand before it checks whether the socket is writable and before the enableOfflineQueue branch, so the budget covers handshake and offline-queue wait as well as execution — any handshake slower than the command deadline failed as Command timed out from a Redis that never received the command (stack contains only ioredis timer frames)
• Derive both deadlines from named constants so the invariant can't drift, and apply the same constant in execution-signal.ts, which was hardcoding its own
• Give the PING health check its own deadline — a probe only runs on an established connection, so it shouldn't inherit a budget sized for handshakes. Keeps failover detection at ~2 intervals
• Warm the shared connection at process start (Trigger.dev init, Next instrumentation) so the first command doesn't pay the handshake inside its own deadline. Establishing TCP+TLS is far more expensive than the commands that run over it, so it should cost once per process, not once per unit of work
• Record an execution log when admission infrastructure is unreachable. That branch returned a failure without one, unlike the denial branch above it, so affected runs vanished from the workspace's logs instead of showing as failed
• Re-admit rather than abort when a reservation refresh throws — a throw previously killed the run before the logging session existed

Type of Change

• Bug fix

Testing

Verified the mechanism against ioredis source (Redis.js sendCommand, Command.js timer lifecycle — armed once, cleared only on settle, never re-armed on queue flush).

New tests cover the timeout invariant, the decoupled probe deadline, and warm-up (already-ready, resolves on ready, gives up at the connect deadline, memoized per client, no-throw when Redis is unconfigured). Confirmed each new guard fails when its fix is reverted and passes when restored.

bun run type-check clean. 3756 tests pass across lib/core, lib/execution, lib/logs, lib/billing, background. bun run lint, block-registry check, and all 37 audits in check:audits pass.

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		Aug 28, 2026 1:12am

[greptile-apps]

Greptile Summary

The PR separates Redis connection, command, and health-probe deadlines, warms shared connections during process initialization, and improves execution behavior around admission infrastructure failures.

• Raises the shared command deadline above the connection deadline and centralizes the value.
• Adds bounded, memoized Redis connection warm-up for Next.js and Trigger.dev processes.
• Uses a dedicated health-probe deadline to preserve timely reconnect detection.
• Records terminal admission-infrastructure failures while suppressing logs for executions that will retry.
• Preserves completed admission when reservation refresh has an ambiguous error, while repeating admission only on a definitive false result.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
apps/sim/background/workflow-execution.ts	Handles ambiguous reservation-refresh errors without repeating admission, resolving the previously reported duplicate-gating failure.
apps/sim/lib/core/config/redis.ts	Centralizes Redis deadlines, adds an independent PING timeout, and provides bounded per-client connection warm-up.
apps/sim/lib/execution/preprocessing.ts	Records admission-infrastructure failures unless retryable failure logging is intentionally suppressed.
apps/sim/trigger.config.ts	Awaits best-effort Redis warm-up during Trigger.dev process initialization.
apps/sim/instrumentation-node.ts	Starts non-blocking Redis warm-up during Next.js instrumentation registration.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Queued workflow starts] --> B{Admission already completed?}
  B -- No --> E[Run preprocessing admission]
  B -- Yes --> C[Refresh reservation expiry]
  C -- true --> D[Keep existing admission]
  C -- false --> E
  C -- throws --> D
  D --> F[Preprocess with usage and rate-limit gates skipped]
  E --> G[Run usage, rate-limit, and reservation gates]
  F --> H[Execute workflow]
  G --> H

Loading

_{Reviews (3): Last reviewed commit: "fix(execution): honor retryable-failure ..." | Re-trigger Greptile}

[cubic-dev-ai]

All reported issues were addressed across 9 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@greptile

[waleedlatif1]

Closing this while we root-cause properly.

The timeout invariant this changes is real, but it treats a symptom: it makes the system tolerate a multi-second stall before a connection becomes usable rather than explaining why that stall happens. Reopening or re-cutting once the underlying cause is understood, so the fix can be aimed at it.