fix(batch-queue): Batch items that hit the environment queue size limit now fast-fail#3352
fix(batch-queue): Batch items that hit the environment queue size limit now fast-fail#3352
Conversation
|
WalkthroughThis pull request implements a fast-fail mechanism for batch items exceeding queue size limits. It introduces a new Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes RationaleThe changes span 7 files with mixed complexity. The core additions include: a new error type definition, special-case error handling with aggregation logic in batch processing, type signature updates for the callback result, and retry scheduling modifications. While the changes follow a cohesive pattern for a single feature, the aggregation condition logic in 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/webapp/app/services/realtime/mintRunToken.server.ts (1)
9-10: Extract the default expiration to a constant to avoid literal drift.This is minor, but it helps keep the default value consistent if it changes later.
♻️ Suggested refactor
import { generateJWT as internal_generateJWT } from "@trigger.dev/core/v3"; import { extractJwtSigningSecretKey } from "./jwtAuth.server"; type Environment = Parameters<typeof extractJwtSigningSecretKey>[0]; +const DEFAULT_RUN_TOKEN_EXPIRATION = "1h"; export type MintRunTokenOptions = { /** Include the input-stream write scope (needed for steering messages from the playground). */ includeInputStreamWrite?: boolean; /** Token expiration. Defaults to "1h". */ @@ return internal_generateJWT({ secretKey: extractJwtSigningSecretKey(environment), payload: { sub: environment.id, pub: true, scopes, }, - expirationTime: options.expirationTime ?? "1h", + expirationTime: options.expirationTime ?? DEFAULT_RUN_TOKEN_EXPIRATION, }); }Also applies to: 39-39
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/webapp/app/services/realtime/mintRunToken.server.ts` around lines 9 - 10, Extract the default expiration literal into a single constant (e.g., DEFAULT_EXPIRATION = '1h') and use that constant wherever the "1h" default appears: replace any inline default for the expirationTime property and the default used in mintRunToken (or related function) so both reference DEFAULT_EXPIRATION; update the JSDoc/comment to reference the constant rather than a hardcoded string to keep defaults consistent if changed later.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/webapp/app/services/realtime/mintRunToken.server.ts`:
- Around line 9-10: Extract the default expiration literal into a single
constant (e.g., DEFAULT_EXPIRATION = '1h') and use that constant wherever the
"1h" default appears: replace any inline default for the expirationTime property
and the default used in mintRunToken (or related function) so both reference
DEFAULT_EXPIRATION; update the JSDoc/comment to reference the constant rather
than a hardcoded string to keep defaults consistent if changed later.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 0cd3e7b4-4381-46e6-987e-076f71e2097e
📒 Files selected for processing (8)
.server-changes/batch-fast-fail-queue-size-limit.mdapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/services/realtime/mintRunToken.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/index.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsinternal-packages/run-engine/src/batch-queue/types.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (18)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: typecheck / typecheck
🧰 Additional context used
📓 Path-based instructions (15)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead
Files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/types.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/types.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries
**/*.ts: Usetypecheckto verify changes in apps and internal packages (apps/*,internal-packages/*), notbuild- building proves almost nothing about correctness
When writing Trigger.dev tasks, always import from@trigger.dev/sdk. Never use@trigger.dev/sdk/v3or deprecatedclient.defineJob
Add crumbs as you write code - mark lines with//@Crumbsor wrap blocks in `// `#region` `@crumbsfor agentcrumbs debug tracing, then strip before merge
Files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/types.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/types.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
apps/webapp/app/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Access all environment variables through the
envexport ofenv.server.tsinstead of directly accessingprocess.envin the Trigger.dev webapp
Files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: When importing from@trigger.dev/corein the webapp, use subpath exports from the package.json instead of importing from the root path
Follow the Remix 2.1.0 and Express server conventions when updating the main trigger.dev webapp
Files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
apps/**/*
📄 CodeRabbit inference engine (CLAUDE.md)
When modifying only server components (
apps/webapp/,apps/supervisor/, etc.) with no package changes, add a.server-changes/file instead of a changeset
Files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
apps/webapp/**/*.server.{ts,tsx}
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
apps/webapp/**/*.server.{ts,tsx}: Environment variables must be accessed via theenvexport fromapp/env.server.tsand never useprocess.envdirectly
Always usefindFirstinstead offindUniquein Prisma queries due to implicit DataLoader batching issues and performance concerns
Files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
apps/webapp/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Use named constants for sentinel/placeholder values instead of raw string literals scattered across comparisons
Files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
apps/webapp/app/v3/services/**/*.server.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Organize services in the webapp following the pattern
app/v3/services/*/*.server.ts
Files:
apps/webapp/app/v3/services/common.server.ts
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use vitest for all tests in the Trigger.dev repository
Files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
**/*.test.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.test.{ts,tsx,js,jsx}: Test files should live beside the files under test and use descriptivedescribeanditblocks
Tests should avoid mocks or stubs and use the helpers from@internal/testcontainerswhen Redis or Postgres are needed
Use vitest for running unit tests
Files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
**/*.test.ts
📄 CodeRabbit inference engine (CLAUDE.md)
Use vitest exclusively for testing and never mock anything - use testcontainers instead for Redis/PostgreSQL
Files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
apps/webapp/app/services/**/*.server.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Separate testable services from configuration files; follow the pattern of
realtimeClient.server.ts(testable service) andrealtimeClientGlobal.server.ts(configuration) in the webapp
Files:
apps/webapp/app/services/realtime/mintRunToken.server.ts
🧠 Learnings (36)
📓 Common learnings
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Use `tasks.batchTrigger()` to trigger multiple runs of a single task from backend code with different payloads
📚 Learning: 2026-03-30T22:25:33.107Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-30T22:25:33.107Z
Learning: Applies to apps/webapp/{app/v3/services/triggerTask.server.ts,app/v3/services/batchTriggerV3.server.ts} : Do NOT add database queries to `triggerTask.server.ts` or `batchTriggerV3.server.ts`; instead piggyback on the existing `backgroundWorkerTask.findFirst()` query in `queues.server.ts`
Applied to files:
.server-changes/batch-fast-fail-queue-size-limit.mdapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-03T13:08:03.862Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3166
File: packages/redis-worker/src/fair-queue/index.ts:1114-1121
Timestamp: 2026-03-03T13:08:03.862Z
Learning: In packages/redis-worker/src/fair-queue/index.ts, it's acceptable for the worker queue depth cap check to allow overshooting by up to batchClaimSize messages per iteration, as the next iteration will recheck and prevent sustained growth beyond the limit.
Applied to files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-04-07T14:12:59.018Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3331
File: apps/webapp/app/runEngine/concerns/batchPayloads.server.ts:112-136
Timestamp: 2026-04-07T14:12:59.018Z
Learning: In `apps/webapp/app/runEngine/concerns/batchPayloads.server.ts`, the `pRetry` call wrapping `uploadPacketToObjectStore` intentionally retries **all** error types (no `shouldRetry` filter / `AbortError` guards). The maintainer explicitly prefers over-retrying to under-retrying because multiple heterogeneous object store backends are supported and it is impractical to enumerate all permanent error signatures. Do not flag this as an issue in future reviews.
Applied to files:
internal-packages/run-engine/src/batch-queue/index.tsinternal-packages/run-engine/src/batch-queue/types.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-03T13:07:33.177Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3166
File: internal-packages/run-engine/src/batch-queue/tests/index.test.ts:711-713
Timestamp: 2026-03-03T13:07:33.177Z
Learning: In `internal-packages/run-engine/src/batch-queue/tests/index.test.ts`, test assertions for rate limiter stubs can use `toBeGreaterThanOrEqual` rather than exact equality (`toBe`) because the consumer loop may call the rate limiter during empty pops in addition to actual item processing, and this over-calling is acceptable in integration tests.
Applied to files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsinternal-packages/run-engine/src/batch-queue/types.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-31T06:25:47.761Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3299
File: internal-packages/run-engine/src/run-queue/index.ts:683-699
Timestamp: 2026-03-31T06:25:47.761Z
Learning: In `internal-packages/run-engine/src/run-queue/index.ts`, message scores passed to `enqueueMessage` are always <= now (computed as `(queueTimestamp || createdAt) - priorityMs`). Future-scored messages (nack retries) never go through `enqueueMessage`; they go directly through `nackMessage` → ZADD to the queue sorted set. Do not flag fast-path enqueue for allowing future-timestamped messages.
Applied to files:
internal-packages/run-engine/src/batch-queue/index.ts
📚 Learning: 2026-03-02T12:43:43.173Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: packages/redis-worker/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:43.173Z
Learning: Applies to packages/redis-worker/**/redis-worker/src/queue.ts : Job queue abstraction should be Redis-backed in src/queue.ts
Applied to files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.ts
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/types.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
internal-packages/run-engine/src/batch-queue/index.tsapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/types.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/services/realtime/mintRunToken.server.ts
📚 Learning: 2026-02-10T16:18:48.654Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 2980
File: apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx:512-515
Timestamp: 2026-02-10T16:18:48.654Z
Learning: In apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx, environment.queueSizeLimit is a per-queue maximum that is configured at the environment level, not a shared limit across all queues. Each queue can have up to environment.queueSizeLimit items queued independently.
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Configure concurrency using the `queue` option with `concurrencyLimit` property
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-30T22:25:33.107Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-30T22:25:33.107Z
Learning: Applies to apps/webapp/app/v3/queues.server.ts : When adding new task-level defaults, add to the existing `select` clause in `backgroundWorkerTask.findFirst()` query in `queues.server.ts` instead of adding a second query
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2025-11-14T16:03:06.917Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2681
File: apps/webapp/app/services/platform.v3.server.ts:258-302
Timestamp: 2025-11-14T16:03:06.917Z
Learning: In `apps/webapp/app/services/platform.v3.server.ts`, the `getDefaultEnvironmentConcurrencyLimit` function intentionally throws an error (rather than falling back to org.maximumConcurrencyLimit) when the billing client returns undefined plan limits. This fail-fast behavior prevents users from receiving more concurrency than their plan entitles them to. The org.maximumConcurrencyLimit fallback is only for self-hosted deployments where no billing client exists.
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task execution time using the `maxDuration` option (in seconds)
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-31T06:25:47.761Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3299
File: internal-packages/run-engine/src/run-queue/index.ts:683-699
Timestamp: 2026-03-31T06:25:47.761Z
Learning: In `internal-packages/run-engine/src/run-queue/index.ts`, the fast-path enqueue (when `enableFastPath` is true) intentionally skips the TTL sorted set. The `expireRun` worker job is scheduled independently *before* `enqueueMessage` is called (in `engine.trigger()`), so TTL expiry is handled regardless of which path the message takes. The slow-path dequeue Lua removes from the TTL set on dequeue (not on enqueue), making the fast-path skip equivalent. Do not suggest adding a `!ttlInfo` guard to the fast-path check — it would prevent nearly all production runs from using the fast path since dev environments default to a 10m TTL.
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `schemaTask()` from `trigger.dev/sdk` with a Zod schema for payload validation
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `task()` from `trigger.dev/sdk` for basic task definitions with `id` and `run` properties
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-31T21:37:31.732Z
Learnt from: isshaddad
Repo: triggerdotdev/trigger.dev PR: 3283
File: docs/migration-n8n.mdx:19-21
Timestamp: 2026-03-31T21:37:31.732Z
Learning: In the trigger.dev SDK (`packages/trigger-sdk/src/v3`), `tasks.triggerAndWait()` and `tasks.batchTriggerAndWait()` are real, valid exported APIs defined in `shared.ts` and re-exported via the `tasks` object in `tasks.ts`. They accept a task ID string as their first argument (not a task instance). These are distinct from the instance methods `yourTask.triggerAndWait()` and `yourTask.batchTriggerAndWait()`. Do not flag `tasks.triggerAndWait()` or `tasks.batchTriggerAndWait()` as non-existent APIs.
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `task.triggerAndWait()` to trigger a task and wait for its result from inside another task
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerAndWait()` to trigger multiple different tasks and wait for all results
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `task.batchTriggerAndWait()` to batch trigger a task and wait for all results from inside another task
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerByTaskAndWait()` to batch trigger multiple tasks by instance and wait for results
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerByTask()` to batch trigger multiple tasks by passing task instances
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `task.trigger()` to trigger a single run of a task from inside another task
Applied to files:
apps/webapp/app/runEngine/services/triggerTask.server.ts
📚 Learning: 2026-03-10T17:56:20.938Z
Learnt from: samejr
Repo: triggerdotdev/trigger.dev PR: 3201
File: apps/webapp/app/v3/services/setSeatsAddOn.server.ts:25-29
Timestamp: 2026-03-10T17:56:20.938Z
Learning: Do not implement local userId-to-organizationId authorization checks inside org-scoped service classes (e.g., SetSeatsAddOnService, SetBranchesAddOnService) in the web app. Rely on route-layer authentication (requireUserId(request)) and org membership enforcement via the _app.orgs.$organizationSlug layout route. Any userId/organizationId that reaches these services from org-scoped routes has already been validated. Apply this pattern across all org-scoped services to avoid redundant auth checks and maintain consistency.
Applied to files:
apps/webapp/app/v3/services/common.server.ts
📚 Learning: 2026-03-29T19:16:28.864Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3291
File: apps/webapp/app/v3/featureFlags.ts:53-65
Timestamp: 2026-03-29T19:16:28.864Z
Learning: When reviewing TypeScript code that uses Zod v3, treat `z.coerce.*()` schemas as their direct Zod type (e.g., `z.coerce.boolean()` returns a `ZodBoolean` with `_def.typeName === "ZodBoolean"`) rather than a `ZodEffects`. Only `.preprocess()`, `.refine()`/`.superRefine()`, and `.transform()` are expected to wrap schemas in `ZodEffects`. Therefore, in reviewers’ logic like `getFlagControlType`, do not flag/unblock failures that require unwrapping `ZodEffects` when the input schema is a `z.coerce.*` schema.
Applied to files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-03T13:07:27.810Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3166
File: internal-packages/run-engine/src/batch-queue/tests/index.test.ts:711-713
Timestamp: 2026-03-03T13:07:27.810Z
Learning: In test files under internal-packages/run-engine/src/batch-queue/tests, prefer asserting using toBeGreaterThanOrEqual for rate limiter behavior when the consumer loop may call the limiter during empty polls as well as during actual processing. This avoids flaky failures due to strict equality, while still validating expected non-decreasing behavior.
Applied to files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
📚 Learning: 2026-03-02T12:43:25.254Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: internal-packages/run-engine/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:25.254Z
Learning: Applies to internal-packages/run-engine/src/engine/tests/**/*.test.ts : Implement tests for RunEngine in `src/engine/tests/` using testcontainers for Redis and PostgreSQL containerization
Applied to files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
📚 Learning: 2026-04-07T14:12:18.946Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3331
File: apps/webapp/test/engine/batchPayloads.test.ts:5-24
Timestamp: 2026-04-07T14:12:18.946Z
Learning: In `apps/webapp/test/engine/batchPayloads.test.ts`, using `vi.mock` for `~/v3/objectStore.server` (stubbing `hasObjectStoreClient` and `uploadPacketToObjectStore`), `~/env.server` (overriding offload thresholds), and `~/v3/tracer.server` (stubbing `startActiveSpan`) is intentional and acceptable. Simulating controlled transient upload failures (e.g., fail N times then succeed) to verify `p-retry` behavior cannot be reproduced with real services or testcontainers. This file is an explicit exception to the repo's general no-mocks policy.
Applied to files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Configure retry behavior using the `retry` option with properties like `maxAttempts`, `factor`, `minTimeoutInMs`, `maxTimeoutInMs`, and `randomize`
Applied to files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
📚 Learning: 2026-03-02T12:43:43.173Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: packages/redis-worker/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:43.173Z
Learning: Applies to packages/redis-worker/**/redis-worker/**/*.{test,spec}.{ts,tsx} : Use testcontainers for Redis in test files for redis-worker
Applied to files:
internal-packages/run-engine/src/batch-queue/tests/index.test.ts
📚 Learning: 2026-03-30T22:25:33.107Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-30T22:25:33.107Z
Learning: Services should call engine methods from `app/v3/runEngine.server.ts` singleton for all run lifecycle operations (triggering, completing, cancelling, etc.)
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-14T10:06:33.506Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3219
File: internal-packages/run-engine/src/run-queue/index.ts:3264-3353
Timestamp: 2026-03-14T10:06:33.506Z
Learning: In `internal-packages/run-engine/src/run-queue/index.ts`, the `dequeueMessagesFromCkQueue` Lua command intentionally dequeues only 1 message per CK sub-queue per iteration (round-robin). This is by design for fairness across concurrency keys (CKs). The `actualMaxCount * 3` scan limit for `ZRANGEBYSCORE` on the CK index is also intentional — it is adequate because each CK independently gets the full queue concurrency limit, so per-CK concurrency blocks rarely occur.
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-02T12:43:25.254Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: internal-packages/run-engine/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:25.254Z
Learning: All new run lifecycle logic should be implemented in the `internal/run-engine` package (`src/engine/`), not directly in `apps/webapp/app/v3/services/`
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2025-11-27T16:26:58.661Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-11-27T16:26:58.661Z
Learning: Applies to apps/webapp/app/services/**/*.server.{ts,tsx} : Separate testable services from configuration files; follow the pattern of `realtimeClient.server.ts` (testable service) and `realtimeClientGlobal.server.ts` (configuration) in the webapp
Applied to files:
apps/webapp/app/services/realtime/mintRunToken.server.ts
📚 Learning: 2026-03-26T09:02:07.973Z
Learnt from: myftija
Repo: triggerdotdev/trigger.dev PR: 3274
File: apps/webapp/app/services/runsReplicationService.server.ts:922-924
Timestamp: 2026-03-26T09:02:07.973Z
Learning: When parsing Trigger.dev task run annotations in server-side services, keep `TaskRun.annotations` strictly conforming to the `RunAnnotations` schema from `trigger.dev/core/v3`. If the code already uses `RunAnnotations.safeParse` (e.g., in a `#parseAnnotations` helper), treat that as intentional/necessary for atomic, schema-accurate annotation handling. Do not recommend relaxing the annotation payload schema or using a permissive “passthrough” parse path, since the annotations are expected to be written atomically in one operation and should not contain partial/legacy payloads that would require a looser parser.
Applied to files:
apps/webapp/app/services/realtime/mintRunToken.server.ts
🔇 Additional comments (16)
.server-changes/batch-fast-fail-queue-size-limit.md (1)
1-7: LGTM!The server-changes file correctly documents the fast-fail behavior for batch items hitting queue size limits, following the project convention for server-only changes.
internal-packages/run-engine/src/batch-queue/index.ts (2)
868-877: LGTM!The
skipRetriesextraction and the updated retry condition correctly implement the fast-fail behavior. The=== truecomparison properly handles cases whereskipRetriesis undefined, and the span attribute provides useful observability.
901-901: LGTM!Comment accurately reflects both code paths (final attempt exhausted OR retries skipped).
apps/webapp/app/runEngine/services/triggerTask.server.ts (2)
44-44: LGTM!Import correctly includes the new
QueueSizeLimitExceededErroralongsideServiceValidationError.
274-279: LGTM!The change to throw
QueueSizeLimitExceededErrorenables downstream batch queue handling to identify this specific failure type and short-circuit retries. The?? 0fallback is defensive coding, thoughmaximumSizeshould always be defined when!queueSizeGuard.ok.apps/webapp/app/v3/services/common.server.ts (1)
13-31: LGTM!The new
QueueSizeLimitExceededErrorclass is well-designed:
- Correctly extends
ServiceValidationErrorfor backward compatibility- Adds the
maximumSizeproperty for downstream use- Sets
this.namefor properinstanceofchecks- JSDoc clearly documents the purpose and cross-references the handler
internal-packages/run-engine/src/batch-queue/types.ts (1)
271-286: LGTM!The type extension is well-designed:
- Optional
skipRetriesfield maintains backward compatibility- JSDoc clearly explains the intended use case (deterministic failures like queue size limits)
- Discriminated union structure with
successboolean remains cleanapps/webapp/app/v3/runEngineHandlers.server.ts (3)
641-648: LGTM!The constant follows the coding guideline for named constants for sentinel values, and the JSDoc clearly documents its purpose and usage across the codebase.
821-850: LGTM!The
QueueSizeLimitExceededErrorhandling is well-implemented:
- Catches the specific error type for targeted handling
- Logs at
warnlevel with appropriate context (no high-cardinality fields)- Sets span attributes for observability
- Returns
skipRetries: trueto bypass the retry ladder- Uses the consistent error code constant
933-977: LGTM!The aggregation logic for queue-size-limit failures is well-designed:
- Correctly identifies when all failures share the same error code using
.every()- Uses the first failure's index as a stable anchor for the unique constraint (enabling idempotent retries)
- Aggregated error message includes the count of affected items
- Falls back to per-item error creation for mixed failure types
skipDuplicates: trueensures callback retry idempotencyThis keeps DB write volume bounded to O(batches) instead of O(items) during queue overload scenarios.
internal-packages/run-engine/src/batch-queue/tests/index.test.ts (4)
779-807: LGTM!The helper function
createBatchQueueWithRetryis well-designed:
- Short retry delays (20-100ms) ensure tests complete quickly even if regression causes full retry exhaustion
- Disabling randomization (
randomize: false) makes test behavior deterministic- Comment explains the rationale for the tiny retry ladder
809-857: LGTM!Excellent test coverage for the primary
skipRetriesbehavior:
- Configures 6 retry attempts but verifies each item is processed exactly once
- Uses the same
QUEUE_SIZE_LIMIT_EXCEEDEDerror code as production- Verifies both attempt counts AND completion result structure
- Uses Redis testcontainers (no mocks) per project guidelines
859-901: LGTM!Important regression guard test ensuring the normal retry path isn't broken:
- Verifies items without
skipRetriesstill exhaust the retry ladder- Clear comment explaining the test's purpose
903-957: LGTM!Excellent per-item behavior test:
- Verifies
skipRetriesis honored on a per-item basis within the same batch- Even-indexed items fast-fail (1 attempt), odd-indexed items retry fully (4 attempts)
- Covers the real-world scenario where only some items in a batch hit the queue limit
apps/webapp/app/services/realtime/mintRunToken.server.ts (2)
1-5: Nice contract alignment via derivedEnvironmenttype.Using
Parameters<typeof extractJwtSigningSecretKey>[0]keeps this service’s input type synced with the auth helper and avoids drift.Based on learnings, this follows “Separate testable services from configuration files; follow the pattern of
realtimeClient.server.ts(testable service) andrealtimeClientGlobal.server.ts(configuration) in the webapp”.
22-41: JWT scope construction and payload shaping look solid.Read scope is always present, write scope is correctly gated, and token minting uses the expected signing key path.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
ericallam
force-pushed
the
ea-branch-124
branch
from
9f71b2d to
f32dc72
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/webapp/app/v3/runEngineHandlers.server.ts (1)
941-963: Aggregation discards per-item details when collapsing errors.When all failures share
QUEUE_SIZE_LIMIT_EXCEEDED, this creates a single error row using only the first failure'staskIdentifier,payload, andoptions. If the batch contained items targeting different tasks, that detail is lost.This is likely acceptable given the design goal (avoid DB amplification during queue overload), but worth confirming this trade-off is intentional. If users need to know which specific tasks failed in a multi-task batch, they'd only see the first item's task identifier.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 8d105b62-8cb1-4961-bd06-fa9fd0b80a87
📒 Files selected for processing (7)
.server-changes/batch-fast-fail-queue-size-limit.mdapps/webapp/app/runEngine/services/triggerTask.server.tsapps/webapp/app/v3/runEngineHandlers.server.tsapps/webapp/app/v3/services/common.server.tsinternal-packages/run-engine/src/batch-queue/index.tsinternal-packages/run-engine/src/batch-queue/tests/index.test.tsinternal-packages/run-engine/src/batch-queue/types.ts
✅ Files skipped from review due to trivial changes (3)
- .server-changes/batch-fast-fail-queue-size-limit.md
- internal-packages/run-engine/src/batch-queue/index.ts
- internal-packages/run-engine/src/batch-queue/tests/index.test.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/webapp/app/runEngine/services/triggerTask.server.ts
- internal-packages/run-engine/src/batch-queue/types.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (18)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: typecheck / typecheck
🧰 Additional context used
📓 Path-based instructions (11)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
apps/webapp/app/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Access all environment variables through the
envexport ofenv.server.tsinstead of directly accessingprocess.envin the Trigger.dev webapp
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: When importing from@trigger.dev/corein the webapp, use subpath exports from the package.json instead of importing from the root path
Follow the Remix 2.1.0 and Express server conventions when updating the main trigger.dev webapp
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
apps/webapp/app/v3/services/**/*.server.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Organize services in the webapp following the pattern
app/v3/services/*/*.server.ts
Files:
apps/webapp/app/v3/services/common.server.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries
**/*.ts: Usetypecheckto verify changes in apps and internal packages (apps/*,internal-packages/*), notbuild- building proves almost nothing about correctness
When writing Trigger.dev tasks, always import from@trigger.dev/sdk. Never use@trigger.dev/sdk/v3or deprecatedclient.defineJob
Add crumbs as you write code - mark lines with//@Crumbsor wrap blocks in `// `#region` `@crumbsfor agentcrumbs debug tracing, then strip before merge
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
apps/**/*
📄 CodeRabbit inference engine (CLAUDE.md)
When modifying only server components (
apps/webapp/,apps/supervisor/, etc.) with no package changes, add a.server-changes/file instead of a changeset
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
apps/webapp/**/*.server.{ts,tsx}
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
apps/webapp/**/*.server.{ts,tsx}: Environment variables must be accessed via theenvexport fromapp/env.server.tsand never useprocess.envdirectly
Always usefindFirstinstead offindUniquein Prisma queries due to implicit DataLoader batching issues and performance concerns
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
apps/webapp/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Use named constants for sentinel/placeholder values instead of raw string literals scattered across comparisons
Files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
🧠 Learnings (15)
📓 Common learnings
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3166
File: packages/redis-worker/src/fair-queue/index.ts:1114-1121
Timestamp: 2026-03-03T13:08:03.862Z
Learning: In packages/redis-worker/src/fair-queue/index.ts, it's acceptable for the worker queue depth cap check to allow overshooting by up to batchClaimSize messages per iteration, as the next iteration will recheck and prevent sustained growth beyond the limit.
📚 Learning: 2026-02-10T16:18:48.654Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 2980
File: apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx:512-515
Timestamp: 2026-02-10T16:18:48.654Z
Learning: In apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx, environment.queueSizeLimit is a per-queue maximum that is configured at the environment level, not a shared limit across all queues. Each queue can have up to environment.queueSizeLimit items queued independently.
Applied to files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-10T17:56:20.938Z
Learnt from: samejr
Repo: triggerdotdev/trigger.dev PR: 3201
File: apps/webapp/app/v3/services/setSeatsAddOn.server.ts:25-29
Timestamp: 2026-03-10T17:56:20.938Z
Learning: Do not implement local userId-to-organizationId authorization checks inside org-scoped service classes (e.g., SetSeatsAddOnService, SetBranchesAddOnService) in the web app. Rely on route-layer authentication (requireUserId(request)) and org membership enforcement via the _app.orgs.$organizationSlug layout route. Any userId/organizationId that reaches these services from org-scoped routes has already been validated. Apply this pattern across all org-scoped services to avoid redundant auth checks and maintain consistency.
Applied to files:
apps/webapp/app/v3/services/common.server.ts
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-29T19:16:28.864Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3291
File: apps/webapp/app/v3/featureFlags.ts:53-65
Timestamp: 2026-03-29T19:16:28.864Z
Learning: When reviewing TypeScript code that uses Zod v3, treat `z.coerce.*()` schemas as their direct Zod type (e.g., `z.coerce.boolean()` returns a `ZodBoolean` with `_def.typeName === "ZodBoolean"`) rather than a `ZodEffects`. Only `.preprocess()`, `.refine()`/`.superRefine()`, and `.transform()` are expected to wrap schemas in `ZodEffects`. Therefore, in reviewers’ logic like `getFlagControlType`, do not flag/unblock failures that require unwrapping `ZodEffects` when the input schema is a `z.coerce.*` schema.
Applied to files:
apps/webapp/app/v3/services/common.server.tsapps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-30T22:25:33.107Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-30T22:25:33.107Z
Learning: Applies to apps/webapp/{app/v3/services/triggerTask.server.ts,app/v3/services/batchTriggerV3.server.ts} : Do NOT add database queries to `triggerTask.server.ts` or `batchTriggerV3.server.ts`; instead piggyback on the existing `backgroundWorkerTask.findFirst()` query in `queues.server.ts`
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-04-07T14:12:59.018Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3331
File: apps/webapp/app/runEngine/concerns/batchPayloads.server.ts:112-136
Timestamp: 2026-04-07T14:12:59.018Z
Learning: In `apps/webapp/app/runEngine/concerns/batchPayloads.server.ts`, the `pRetry` call wrapping `uploadPacketToObjectStore` intentionally retries **all** error types (no `shouldRetry` filter / `AbortError` guards). The maintainer explicitly prefers over-retrying to under-retrying because multiple heterogeneous object store backends are supported and it is impractical to enumerate all permanent error signatures. Do not flag this as an issue in future reviews.
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-03T13:08:03.862Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3166
File: packages/redis-worker/src/fair-queue/index.ts:1114-1121
Timestamp: 2026-03-03T13:08:03.862Z
Learning: In packages/redis-worker/src/fair-queue/index.ts, it's acceptable for the worker queue depth cap check to allow overshooting by up to batchClaimSize messages per iteration, as the next iteration will recheck and prevent sustained growth beyond the limit.
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2025-11-14T16:03:06.917Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2681
File: apps/webapp/app/services/platform.v3.server.ts:258-302
Timestamp: 2025-11-14T16:03:06.917Z
Learning: In `apps/webapp/app/services/platform.v3.server.ts`, the `getDefaultEnvironmentConcurrencyLimit` function intentionally throws an error (rather than falling back to org.maximumConcurrencyLimit) when the billing client returns undefined plan limits. This fail-fast behavior prevents users from receiving more concurrency than their plan entitles them to. The org.maximumConcurrencyLimit fallback is only for self-hosted deployments where no billing client exists.
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-30T22:25:33.107Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-30T22:25:33.107Z
Learning: Applies to apps/webapp/app/v3/queues.server.ts : When adding new task-level defaults, add to the existing `select` clause in `backgroundWorkerTask.findFirst()` query in `queues.server.ts` instead of adding a second query
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-14T10:06:33.506Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3219
File: internal-packages/run-engine/src/run-queue/index.ts:3264-3353
Timestamp: 2026-03-14T10:06:33.506Z
Learning: In `internal-packages/run-engine/src/run-queue/index.ts`, the `dequeueMessagesFromCkQueue` Lua command intentionally dequeues only 1 message per CK sub-queue per iteration (round-robin). This is by design for fairness across concurrency keys (CKs). The `actualMaxCount * 3` scan limit for `ZRANGEBYSCORE` on the CK index is also intentional — it is adequate because each CK independently gets the full queue concurrency limit, so per-CK concurrency blocks rarely occur.
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-03T13:07:33.177Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3166
File: internal-packages/run-engine/src/batch-queue/tests/index.test.ts:711-713
Timestamp: 2026-03-03T13:07:33.177Z
Learning: In `internal-packages/run-engine/src/batch-queue/tests/index.test.ts`, test assertions for rate limiter stubs can use `toBeGreaterThanOrEqual` rather than exact equality (`toBe`) because the consumer loop may call the rate limiter during empty pops in addition to actual item processing, and this over-calling is acceptable in integration tests.
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-30T22:25:33.107Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-30T22:25:33.107Z
Learning: Services should call engine methods from `app/v3/runEngine.server.ts` singleton for all run lifecycle operations (triggering, completing, cancelling, etc.)
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
📚 Learning: 2026-03-25T15:29:25.889Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2026-03-25T15:29:25.889Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Configure concurrency using the `queue` option with `concurrencyLimit` property
Applied to files:
apps/webapp/app/v3/runEngineHandlers.server.ts
🔇 Additional comments (4)
apps/webapp/app/v3/services/common.server.ts (1)
14-31: LGTM!The new error class is well-designed. It properly extends
ServiceValidationError, exposesmaximumSizefor consumers to access queue limit information, and the JSDoc clearly explains its purpose for batch queue retry short-circuiting.apps/webapp/app/v3/runEngineHandlers.server.ts (3)
16-16: LGTM!Import correctly references the new error class from the internal services module.
641-648: LGTM!Good use of a named constant for the error code, following the coding guideline for sentinel values. The JSDoc clearly documents the integration with BatchQueue and completion callback.
821-850: LGTM!Excellent error handling design:
- Specific catch before generic error handling
- Appropriate
warnlog level for a customer-overload scenarioskipRetries: truecorrectly signals the BatchQueue to fast-fail- Span attributes provide good observability without high-cardinality metric concerns
2 participants
No description provided.