Conversation
Member
matt-aitken
commented
Mar 15, 2026
matt-aitken
commented
- Added a new ascii diagram
- Removed some old references
|
Contributor
WalkthroughThe README for the run-engine package was reworked: added an Overview diagram and a RunEngine System Architecture diagram; replaced WorkerGroup terminology with Regions; removed legacy RunCreated/Delayed states and waitpoint-focused sections; shifted run flow to token-based waits (renaming wait.forWaitpoint to wait.forToken) with emphasis on concurrency limits and debouncing; simplified queue-pulling to region-based APIs; removed throttling/batching/rate-limiting subsections; retained and repositioned run locking/Redlock discussion; updated code examples to reflect token-based flows. No exported/public API declarations changed. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| @@ -125,17 +211,34 @@ Wait until a request has been received at the URL that you are given. This is us | |||
| A more advanced SDK which would require uses to explicitly create a waitpoint. We would also need `createWaitpoint()`, `completeWaitpoint()`, and `failWaitpoint()`. | |||
Contributor
There was a problem hiding this comment.
🟡 Section heading still references old API wait.forWaitpoint while code examples use new wait.forToken
The section heading at line 209 still says wait.forWaitpoint(waitpointId) and the description at line 211 still references the old API names (createWaitpoint(), completeWaitpoint(), failWaitpoint()), but the code examples were updated to use the new token-based API (wait.createToken, wait.forToken, wait.completeToken, wait.retrieveToken). This makes the documentation internally contradictory.
(Refers to lines 209-211)
Was this helpful? React with 👍 or 👎 to provide feedback.
Comment on lines
+221
to
+222
| const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); | ||
| const waitpoint = await wait.retrieveToken(waitpoint.id); |
Contributor
There was a problem hiding this comment.
🟡 Duplicate const waitpoint declaration in code example causes syntax error
Lines 221-222 both declare const waitpoint, which is a SyntaxError in JavaScript/TypeScript (Identifier 'waitpoint' has already been declared). The second declaration should use a different variable name or use let/reassignment.
Suggested change
| const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); | |
| const waitpoint = await wait.retrieveToken(waitpoint.id); | |
| const token = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); | |
| const retrieved = await wait.retrieveToken(token.id); |
Was this helpful? React with 👍 or 👎 to provide feedback.
Comment on lines
+224
to
+226
| await wait.completeToken<ApprovalToken>(tokenId, { | ||
| status: "approved", | ||
| }); |
Contributor
There was a problem hiding this comment.
🟡 Undefined variable tokenId referenced in code example
Line 224 references tokenId which is never declared in the code block. Based on the preceding lines, this should be token.id (or waitpoint.id prior to the fix for the duplicate declaration).
Suggested change
| await wait.completeToken<ApprovalToken>(tokenId, { | |
| status: "approved", | |
| }); | |
| await wait.completeToken<ApprovalToken>(token.id, { | |
| status: "approved", | |
| }); |
Was this helpful? React with 👍 or 👎 to provide feedback.
Comment on lines
266
to
267
|
|
||
| We should mark the run as `"DELAYED"` with the correct `delayUntil` time. This will allow the user to see that the run is delayed and why. |
Contributor
There was a problem hiding this comment.
🚩 Removed sections on Rate Limiting, Throttling, and Batching may still be relevant future plans
The PR removes documentation sections for Rate limiting, Throttling, and Batching from the "Run flow control" section (old lines 160-197). These appeared to describe planned/future features. Their removal simplifies the README to focus on what's currently implemented (Concurrency limits and Debouncing), which is reasonable. However, if these are still planned features, removing them from the internal design doc could lose institutional knowledge. Not a bug, but worth the reviewer confirming these features are no longer planned.
(Refers to lines 251-267)
Was this helpful? React with 👍 or 👎 to provide feedback.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal-packages/run-engine/README.md`:
- Line 151: Change the possessive typo in the sentence "A worker will call the
Trigger.dev API with it's `region`." to use "its" instead of "it's" so it reads
"A worker will call the Trigger.dev API with its `region`." Update the README
line containing that exact sentence.
- Around line 221-223: The example declares const waitpoint twice which is
invalid TypeScript; change the second declaration to use a new variable name
(e.g., retrievedWaitpoint or waitpointToken) and assign the result of
wait.retrieveToken(waitpoint.id) to that new variable so you only declare
waitpoint once and then store the retrieved token in the new identifier; update
any subsequent references accordingly (functions: wait.createToken,
wait.retrieveToken; identifier: waitpoint).
- Around line 24-121: The fenced ASCII-art code block in README.md is missing a
language tag which triggers MD040; locate the triple-backtick block that
contains the large ASCII "Run triggered" diagram and change the opening fence
from ``` to ```text (i.e., add the language identifier "text") so the block is
properly annotated and markdown linting passes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: b0fc5a1e-90b3-4197-b28a-0fe028cb7d88
⛔ Files ignored due to path filters (1)
internal-packages/run-engine/execution-states.pngis excluded by!**/*.png
📒 Files selected for processing (1)
internal-packages/run-engine/README.md
📜 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). (27)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: sdk-compat / Bun Runtime
- GitHub Check: typecheck / typecheck
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
internal-packages/run-engine/README.md
🧠 Learnings (30)
📓 Common learnings
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-13T13:37:49.544Z
Learning: Applies to **/*.{ts,tsx} : Use Run Engine 2.0 (internal/run-engine) and redis-worker for all new work - avoid DEPRECATED zodworker (Graphile-worker wrapper)
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/`
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-11-27T16:26:58.661Z
Learning: Use the Run Engine 2.0 from `internal/run-engine` for new run lifecycle code in the webapp instead of the legacy run engine
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: internal-packages/database/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:17.177Z
Learning: New code should always target Prisma RunEngineVersion V2 (run-engine + redis-worker), not V1 (legacy MarQS + Graphile)
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: All run lifecycle operations (triggering, completing, cancelling, etc.) should be performed through the singleton run engine instance in `app/v3/runEngine.server.ts` via service calls
📚 Learning: 2026-03-13T13:37:49.544Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-13T13:37:49.544Z
Learning: Applies to **/*.{ts,tsx} : Use Run Engine 2.0 (internal/run-engine) and redis-worker for all new work - avoid DEPRECATED zodworker (Graphile-worker wrapper)
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use the Run Engine 2.0 from `internal/run-engine` for new run lifecycle code in the webapp instead of the legacy run engine
Applied to files:
internal-packages/run-engine/README.md
📚 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:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:42:56.114Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: All run lifecycle operations (triggering, completing, cancelling, etc.) should be performed through the singleton run engine instance in `app/v3/runEngine.server.ts` via service calls
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:43:17.177Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: internal-packages/database/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:17.177Z
Learning: New code should always target Prisma RunEngineVersion V2 (run-engine + redis-worker), not V1 (legacy MarQS + Graphile)
Applied to files:
internal-packages/run-engine/README.md
📚 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/systems/**/*.ts : Integrate OpenTelemetry tracer and meter instrumentation in RunEngine systems for observability
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use Redis for distributed locks and queues in the RunEngine system via `RunQueue` and `RunLocker` utilities
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:42:56.114Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: Applies to apps/webapp/app/v3/*Worker.server.ts : New background job workers should use `trigger.dev/redis-worker` (e.g., `commonWorker.server.ts`, `alertsWorker.server.ts`, `batchTriggerWorker.server.ts`), not zodworker or graphile-worker
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use `trigger.dev/redis-worker` for background job and worker system needs in the webapp and run engine
Applied to files:
internal-packages/run-engine/README.md
📚 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/**/*@(job|queue|worker|background).{ts,tsx} : Use trigger.dev/redis-worker for all new background job implementations, replacing graphile-worker and zodworker
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-07-18T12:50:37.351Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2277
File: apps/webapp/app/presenters/v3/VersionListPresenter.server.ts:62-65
Timestamp: 2025-07-18T12:50:37.351Z
Learning: Background workers don't share versions in the trigger.dev system, meaning each backgroundWorker record has a unique version field, so DISTINCT clauses are not needed when querying for versions.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `task()` function from `trigger.dev/sdk/v3` to define tasks with id and run properties
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-02-25T17:28:20.456Z
Learnt from: isshaddad
Repo: triggerdotdev/trigger.dev PR: 3130
File: docs/v3-openapi.yaml:3134-3135
Timestamp: 2026-02-25T17:28:20.456Z
Learning: In the Trigger.dev codebase, the `publicAccessToken` returned by the SDK's `wait.createToken()` method is not part of the HTTP response body from `POST /api/v1/waitpoints/tokens`. The server returns only `{ id, isCached, url }`. The SDK's `prepareData` hook generates the JWT client-side from the `x-trigger-jwt-claims` response header after the HTTP call completes. The OpenAPI spec correctly documents only the HTTP response body, not SDK transformations.
<!-- [/add_learning]
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.triggerAndWait()` to trigger a task and wait for its result from a parent task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerAndWait()` to batch trigger multiple different tasks and wait for results
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerByTaskAndWait()` to batch trigger tasks by passing task instances and wait for results
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.batchTriggerAndWait()` to batch trigger tasks and wait for all results from a parent task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `schemaTask()` from `trigger.dev/sdk/v3` with Zod schema for payload validation
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `idempotencyKeys.create()` to create idempotency keys for preventing duplicate task executions
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-05-07T09:59:03.771Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2025
File: apps/webapp/app/routes/api.v1.waitpoints.http-callback.$waitpointFriendlyId.callback.ts:0-0
Timestamp: 2025-05-07T09:59:03.771Z
Learning: Matt implemented a cryptographic hash in webhook callback URLs using HMAC-SHA256 with the API key as the secret to prevent unauthorized completion of waitpoints in the Trigger.dev platform.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.batchTrigger()` to trigger multiple runs of a task from inside another task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `idempotencyKeyTTL` option to define a time window during which duplicate triggers return the original run
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Subscribe to run updates using `runs.subscribeToRun()` for realtime monitoring of task execution
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `tasks.batchTrigger()` to trigger multiple runs of a single task with different payloads
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Control concurrency using the `queue` property with `concurrencyLimit` option
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.trigger()` to trigger multiple different tasks at once from backend code
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task duration using the `maxDuration` property (in seconds)
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `runs.subscribeToBatch()` to subscribe to changes for all runs in a batch
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `runs.subscribeToRunsWithTag()` to subscribe to all runs with a specific tag
Applied to files:
internal-packages/run-engine/README.md
🪛 markdownlint-cli2 (0.21.0)
internal-packages/run-engine/README.md
[warning] 24-24: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
Comment on lines
+24
to
+121
| ``` | ||
| ╔═══════════════════════════════╗ | ||
| ║ ║░ | ||
| ║ Run triggered ║░ | ||
| ║ ║░ | ||
| ╚═══════════════════════════════╝░ | ||
| ___ ___ _ ░░░░░░░░░░░░░░░│░░░░░░░░░░░░░░░░░ | ||
| | _ \_ _ _ _ | __|_ _ __ _(_)_ _ ___ │ | ||
| ╔══| / || | ' \ | _|| ' \/ _` | | ' \/ -_)═════════════════════════════╬══════════════════════════════════════╗ | ||
| ║ |_|_\\_,_|_||_| |___|_||_\__, |_|_||_\___| │ ║ | ||
| ║ |___/ │ ║ | ||
| ║ │ ║ | ||
| ║ ┌────────────────────────────────────── Has delay/debounce? ║ | ||
| ║ │ │ ║ | ||
| ║ Yes No ║ | ||
| ║ │ │ ║ | ||
| ║ ▼ ▼ ║ | ||
| ║ ╔═══════════════════════════════╗ ╔═══════════════════════════════╗ ║ | ||
| ║ ║ ║ Delay/ ║ ║ ║ | ||
| ║ ║ DELAYED ║◀────debounce────║ RUN_CREATED ║ ║ | ||
| ║ ║ ║ ║ ║ ║ | ||
| ║ ╚═══════════════════════════════╝ ╚═══════════════════════════════╝ ║ | ||
| ║ │ │ ║ | ||
| ║ │ │ ║ | ||
| ║ +===============================+ No delay/debounce ║ | ||
| ║ | | │ ║ | ||
| ║ | Redis Worker | │ ║ | ||
| ║ | | ▼ ║ | ||
| ║ +===============================+ ╔═══════════════════════════════╗ ║ | ||
| ║ │ ║ ║ ║ | ||
| ║ └───────────After delay──────────▶║ QUEUED ║◀────────────┐ ║ | ||
| ║ ║ ║ │ ║ | ||
| ║ ╚═══════════════════════════════╝ │ ║ | ||
| ║ ┌────All Waitpoints complete?─────┐ │ │ ║ | ||
| ║ │ │ │ │ ║ | ||
| ║ │ ▼ ▼ │ ║ | ||
| ║ ╔═══════════════════════════════╗ +===============================+ │ ║ | ||
| ║ ║ ║ | | Slow retry ║ | ||
| ║ ║ SUSPENDED ║ | Run Queue | │ ║ | ||
| ║ ║ ║ | | │ ║ | ||
| ║ ╚═══════════════════════════════╝ +===============================+ │ ║ | ||
| Run not executing ║ ▲ │ ║ | ||
| ║ │ │ │ ║ | ||
| ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ╬ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ╬ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ╬ ═ ═ ═ ═║═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ | ||
| ║ │ │ │ ║ | ||
| Run maybe executing ║ │ │ ║ ╔═══════════════════════════════╗ | ||
| ║ │ │ │ ║ ║ ║░ | ||
| ║ │ Pulled from the queue ◀─────────────────┼────────╬───◈║ Dequeue a run ║░ | ||
| ║ │ │ │ ║ ║ ║░ | ||
| ║ │ ▼ │ ║ ╚═══════════════════════════════╝░ | ||
| ║ │ ╔═══════════════════════════════╗ │ ║ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | ||
| ║ │ ║ ║ │ ║ | ||
| ║ │ ║ PENDING_EXECUTING ║ │ ║ | ||
| ╔═══════════════════════════════╗ ║ │ ║ ║ │ ║ | ||
| ║ ║░ ║ │ ╚═══════════════════════════════╝ │ ║ | ||
| ║ Checkpoint created ║◈───╬───────────────────────┤ │ │ ║ ╔═══════════════════════════════╗ | ||
| ║ ║░ ║ │ ║ ║ ║░ | ||
| ╚═══════════════════════════════╝░ ║ │ ├─────────────────────────────┼────────╬───◈║ Start attempt ║░ | ||
| ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ │ │ ║ ║ ║░ | ||
| ║ │ ▼ │ ║ ╚═══════════════════════════════╝░ | ||
| ║ All Is executing on worker │ ║ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | ||
| ║ │ ┌────Waitpoints───┐ │ ┌─Quick retry │ ║ | ||
| ║ │ complete? │ │ │ │ │ ║ | ||
| ║ │ │ ▼ ▼ ▼ │ │ ║ | ||
| ║ ╔═══════════════════════════════╗ ╔═══════════════════════════════╗ │ │ ║ | ||
| ║ ║ ║ Hits a ║ ║ │ │ ║ | ||
| ║ ║ EXECUTING_WITH_WAITPOINTS ║◀───Waitpoint────║ EXECUTING ║ │ │ ║ | ||
| ║ ║ ║ ║ ║ │ │ ║ | ||
| ║ ╚═══════════════════════════════╝ ╚═══════════════════════════════╝ │ │ ║ | ||
| ║ │ │ │ ║ ╔═══════════════════════════════╗ | ||
| ║ │ │ ║ ║ ║░ | ||
| ║ ◀──────────────────────┼──────┼────────╬───◈║ Complete attempt ║░ | ||
| ║ │ │ │ ║ ║ ║░ | ||
| ║ │ │ │ ║ ╚═══════════════════════════════╝░ | ||
| ║ │ │ │ ║ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | ||
| ║ ├───────────────▶ Attempt failed ║ | ||
| ║ │ │ ║ | ||
| ║ Attempt success │ ║ | ||
| ║ │ All retries ║ | ||
| ║ ▼ used ║ | ||
| ╔═══════════════════════════════╗ ║ ╔═══════════════════════════════╗ │ ║ | ||
| ║ ║░ ║ ║ ║ │ ║ | ||
| ║ User cancels a run ║────╬──────────────▶ Is executing? ─────────── No ─────────▶║ FINISHED ║◀───────┘ ║ | ||
| ║ ║░ ║ │ ║ ║ ║ | ||
| ╚═══════════════════════════════╝░ ║ Yes ╚═══════════════════════════════╝ ║ | ||
| ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ │ ▲ ║ | ||
| ║ ▼ │ ║ | ||
| ║ ╔═══════════════════════════════╗ │ ║ | ||
| ║ ║ ║ │ ║ | ||
| ║ ║ PENDING_CANCEL ║─────────────────────────────────┘ ║ | ||
| ║ ║ ║ ║ | ||
| ║ ╚═══════════════════════════════╝ ║ | ||
| ║ ║ | ||
| ║ ║ | ||
| ║ ║ | ||
| ╚════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝ | ||
|
|
||
| ``` |
Contributor
There was a problem hiding this comment.
Add a language to the fenced ASCII diagram block.
Line 24 starts a fenced block without a language, which triggers MD040 and breaks markdown linting consistency.
Suggested fix
-```
+```text
...
-```
+```🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 24-24: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@internal-packages/run-engine/README.md` around lines 24 - 121, The fenced
ASCII-art code block in README.md is missing a language tag which triggers
MD040; locate the triple-backtick block that contains the large ASCII "Run
triggered" diagram and change the opening fence from ``` to ```text (i.e., add
the language identifier "text") so the block is properly annotated and markdown
linting passes.
| For dev environments, we will pass the `environment` id. | ||
|
|
||
| If there's only a `workerGroup`, we can just `dequeueFromMasterQueue()` to get runs. If there's a `BackgroundWorker` id, we need to determine if that `BackgroundWorker` is the latest. If it's the latest we call `dequeueFromEnvironmentMasterQueue()` to get any runs that aren't locked to a version. If it's not the latest, we call `dequeueFromBackgroundWorkerMasterQueue()` to get runs that are locked to that version. | ||
| A worker will call the Trigger.dev API with it's `region`. For dev environments, we will pass the `environment` id. |
Contributor
There was a problem hiding this comment.
Fix possessive typo in user-facing docs.
Line 151 should use its (possessive), not it's (contraction), in “with its region”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@internal-packages/run-engine/README.md` at line 151, Change the possessive
typo in the sentence "A worker will call the Trigger.dev API with it's
`region`." to use "its" instead of "it's" so it reads "A worker will call the
Trigger.dev API with its `region`." Update the README line containing that exact
sentence.
Comment on lines
+221
to
223
| const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); | ||
| const waitpoint = await wait.retrieveToken(waitpoint.id); | ||
|
|
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Read-only verification: find duplicate const declaration in the same snippet context
rg -n -C2 'const waitpoint = await wait\.(createToken|retrieveToken)\(' internal-packages/run-engine/README.mdRepository: triggerdotdev/trigger.dev
Length of output: 299
🏁 Script executed:
#!/bin/bash
# Get the full context around the problematic lines
sed -n '210,235p' internal-packages/run-engine/README.md | cat -nRepository: triggerdotdev/trigger.dev
Length of output: 1029
Fix invalid TypeScript syntax in the token example (duplicate const declaration).
Lines 221–222 both declare const waitpoint in the same scope, which is invalid TypeScript. The second declaration should use a different variable name.
Suggested fix
const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` });
-const waitpoint = await wait.retrieveToken(waitpoint.id);
+const retrievedToken = await wait.retrieveToken(waitpoint.id);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); | |
| const waitpoint = await wait.retrieveToken(waitpoint.id); | |
| const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); | |
| const retrievedToken = await wait.retrieveToken(waitpoint.id); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@internal-packages/run-engine/README.md` around lines 221 - 223, The example
declares const waitpoint twice which is invalid TypeScript; change the second
declaration to use a new variable name (e.g., retrievedWaitpoint or
waitpointToken) and assign the result of wait.retrieveToken(waitpoint.id) to
that new variable so you only declare waitpoint once and then store the
retrieved token in the new identifier; update any subsequent references
accordingly (functions: wait.createToken, wait.retrieveToken; identifier:
waitpoint).
- Added a new ascii diagram - Removed some old references
| const waitpoint = await waitpoints.complete(waitpoint.id, result); | ||
| const waitpoint = await waitpoints.fail(waitpoint.id, error); | ||
| // Your backend | ||
| import { wait } from "@trigger.dev/sdk"; |
Contributor
There was a problem hiding this comment.
📝 Info: Import path uses @trigger.dev/sdk instead of @trigger.dev/sdk/v3
The code example at line 215 imports from @trigger.dev/sdk which is actually correct for the wait API (consistent with official docs at docs/wait-for-token.mdx:19). The .cursor/rules/writing-tasks.mdc rule requiring @trigger.dev/sdk/v3 applies specifically to task definitions, not backend utility imports like wait. No issue here.
Was this helpful? React with 👍 or 👎 to provide feedback.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
internal-packages/run-engine/README.md (3)
221-222:⚠️ Potential issue | 🟠 MajorFix duplicate variable declaration.
Lines 221-222 both declare
const waitpoint, which is invalid TypeScript. The second declaration should use a different variable name.🐛 Suggested fix
const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); -const waitpoint = await wait.retrieveToken(waitpoint.id); +const retrievedToken = await wait.retrieveToken(waitpoint.id);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` around lines 221 - 222, The code declares `const waitpoint` twice (once from wait.createToken and again from wait.retrieveToken) which is invalid; rename the second variable returned by `wait.retrieveToken(waitpoint.id)` (for example to `retrievedWaitpoint` or `waitpointToken`) and update any subsequent references to use that new identifier so the original `waitpoint` from `wait.createToken` remains distinct.
24-24:⚠️ Potential issue | 🟡 MinorAdd a language identifier to the fenced code block.
The ASCII diagram block is missing a language tag, which triggers the MD040 markdown linting rule.
📝 Suggested fix
-``` +```text🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` at line 24, The fenced ASCII diagram in the README is missing a language identifier which triggers MD040; update the triple-backtick fence around the diagram (the ASCII diagram block) to include a language tag such as "text" (e.g., change ``` to ```text) so the markdown linter accepts the block.
151-151:⚠️ Potential issue | 🟡 MinorFix possessive typo.
Use "its" (possessive) instead of "it's" (contraction of "it is").
📝 Suggested fix
-A worker will call the Trigger.dev API with it's `region`. For dev environments, we will pass the `environment` id. +A worker will call the Trigger.dev API with its `region`. For dev environments, we will pass the `environment` id.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` at line 151, Replace the incorrect contraction "it's" with the possessive "its" in the README sentence "A worker will call the Trigger.dev API with it's `region`." so it reads "A worker will call the Trigger.dev API with its `region`." — update the line containing that exact sentence in internal-packages/run-engine/README.md (look for "A worker will call the Trigger.dev API with it's `region`.") and commit the change.
🧹 Nitpick comments (1)
internal-packages/run-engine/README.md (1)
147-147: Clarify terminology: region vs. worker group.The sentence uses "region" but ends with "for that worker group," which may confuse readers. Given the shift to region-based terminology mentioned in the PR objectives, consider updating this to use consistent terminology.
📝 Suggested fix
-Then when triggering runs, you can override the `region` to use. The region is used internally to set the `masterQueue` that a run is placed in, this allows pulling runs only for that worker group. +Then when triggering runs, you can override the `region` to use. The region is used internally to set the `masterQueue` that a run is placed in, which allows pulling runs only for that region.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` at line 147, The README sentence mixes terminology—use "region" consistently instead of "worker group": update the sentence that mentions overriding the `region` and the `masterQueue` mapping so it reads that the region determines the `masterQueue` a run is placed in, allowing pulling runs only for that region; keep the `masterQueue` and `region` identifiers as-is so readers can map the behavior to the code/config.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal-packages/run-engine/README.md`:
- Line 211: Fix the grammatical typo in the README sentence: change "uses" to
"users" in the line that reads "A more advanced SDK which would require uses to
explicitly create a waitpoint." Update the sentence that mentions
createWaitpoint(), completeWaitpoint(), and failWaitpoint() so it reads
"...would require users to explicitly create a waitpoint." to correct the
grammar.
---
Duplicate comments:
In `@internal-packages/run-engine/README.md`:
- Around line 221-222: The code declares `const waitpoint` twice (once from
wait.createToken and again from wait.retrieveToken) which is invalid; rename the
second variable returned by `wait.retrieveToken(waitpoint.id)` (for example to
`retrievedWaitpoint` or `waitpointToken`) and update any subsequent references
to use that new identifier so the original `waitpoint` from `wait.createToken`
remains distinct.
- Line 24: The fenced ASCII diagram in the README is missing a language
identifier which triggers MD040; update the triple-backtick fence around the
diagram (the ASCII diagram block) to include a language tag such as "text"
(e.g., change ``` to ```text) so the markdown linter accepts the block.
- Line 151: Replace the incorrect contraction "it's" with the possessive "its"
in the README sentence "A worker will call the Trigger.dev API with it's
`region`." so it reads "A worker will call the Trigger.dev API with its
`region`." — update the line containing that exact sentence in
internal-packages/run-engine/README.md (look for "A worker will call the
Trigger.dev API with it's `region`.") and commit the change.
---
Nitpick comments:
In `@internal-packages/run-engine/README.md`:
- Line 147: The README sentence mixes terminology—use "region" consistently
instead of "worker group": update the sentence that mentions overriding the
`region` and the `masterQueue` mapping so it reads that the region determines
the `masterQueue` a run is placed in, allowing pulling runs only for that
region; keep the `masterQueue` and `region` identifiers as-is so readers can map
the behavior to the code/config.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 71febfe2-6547-4a74-8de8-ba2cd2c9fc65
📒 Files selected for processing (1)
internal-packages/run-engine/README.md
📜 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). (27)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 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 (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
- GitHub Check: sdk-compat / Bun Runtime
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: typecheck / typecheck
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
internal-packages/run-engine/README.md
🧠 Learnings (29)
📓 Common learnings
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-13T13:37:49.544Z
Learning: Applies to **/*.{ts,tsx} : Use Run Engine 2.0 (internal/run-engine) and redis-worker for all new work - avoid DEPRECATED zodworker (Graphile-worker wrapper)
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/`
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: All run lifecycle operations (triggering, completing, cancelling, etc.) should be performed through the singleton run engine instance in `app/v3/runEngine.server.ts` via service calls
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-11-27T16:26:58.661Z
Learning: Use the Run Engine 2.0 from `internal/run-engine` for new run lifecycle code in the webapp instead of the legacy run engine
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: internal-packages/database/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:17.177Z
Learning: New code should always target Prisma RunEngineVersion V2 (run-engine + redis-worker), not V1 (legacy MarQS + Graphile)
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: Use Redis for distributed locks and queues in the RunEngine system via `RunQueue` and `RunLocker` utilities
📚 Learning: 2026-03-13T13:37:49.544Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-13T13:37:49.544Z
Learning: Applies to **/*.{ts,tsx} : Use Run Engine 2.0 (internal/run-engine) and redis-worker for all new work - avoid DEPRECATED zodworker (Graphile-worker wrapper)
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use the Run Engine 2.0 from `internal/run-engine` for new run lifecycle code in the webapp instead of the legacy run engine
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:42:56.114Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: All run lifecycle operations (triggering, completing, cancelling, etc.) should be performed through the singleton run engine instance in `app/v3/runEngine.server.ts` via service calls
Applied to files:
internal-packages/run-engine/README.md
📚 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:
internal-packages/run-engine/README.md
📚 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/systems/**/*.ts : Integrate OpenTelemetry tracer and meter instrumentation in RunEngine systems for observability
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-10T12:44:19.869Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:19.869Z
Learning: In the triggerdotdev/trigger.dev repository, docs PRs are often written as companions to implementation PRs (e.g., PR `#3200` documents features being added in PR `#3196`). When reviewing docs PRs, the documented features may exist in a companion/companion PR branch rather than main. Always check companion PRs referenced in the PR description before flagging missing implementations.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:43:02.539Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:02.539Z
Learning: Applies to docs/**/*.mdx : Use language tags in code fences: `typescript`, `bash`, `json`
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use Redis for distributed locks and queues in the RunEngine system via `RunQueue` and `RunLocker` utilities
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:42:56.114Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: Applies to apps/webapp/app/v3/*Worker.server.ts : New background job workers should use `trigger.dev/redis-worker` (e.g., `commonWorker.server.ts`, `alertsWorker.server.ts`, `batchTriggerWorker.server.ts`), not zodworker or graphile-worker
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use `trigger.dev/redis-worker` for background job and worker system needs in the webapp and run engine
Applied to files:
internal-packages/run-engine/README.md
📚 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/**/*@(job|queue|worker|background).{ts,tsx} : Use trigger.dev/redis-worker for all new background job implementations, replacing graphile-worker and zodworker
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-07-18T12:50:37.351Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2277
File: apps/webapp/app/presenters/v3/VersionListPresenter.server.ts:62-65
Timestamp: 2025-07-18T12:50:37.351Z
Learning: Background workers don't share versions in the trigger.dev system, meaning each backgroundWorker record has a unique version field, so DISTINCT clauses are not needed when querying for versions.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `task()` function from `trigger.dev/sdk/v3` to define tasks with id and run properties
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-02-25T17:28:20.456Z
Learnt from: isshaddad
Repo: triggerdotdev/trigger.dev PR: 3130
File: docs/v3-openapi.yaml:3134-3135
Timestamp: 2026-02-25T17:28:20.456Z
Learning: In the Trigger.dev codebase, the `publicAccessToken` returned by the SDK's `wait.createToken()` method is not part of the HTTP response body from `POST /api/v1/waitpoints/tokens`. The server returns only `{ id, isCached, url }`. The SDK's `prepareData` hook generates the JWT client-side from the `x-trigger-jwt-claims` response header after the HTTP call completes. The OpenAPI spec correctly documents only the HTTP response body, not SDK transformations.
<!-- [/add_learning]
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.triggerAndWait()` to trigger a task and wait for its result from a parent task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerAndWait()` to batch trigger multiple different tasks and wait for results
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-05-07T09:59:03.771Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2025
File: apps/webapp/app/routes/api.v1.waitpoints.http-callback.$waitpointFriendlyId.callback.ts:0-0
Timestamp: 2025-05-07T09:59:03.771Z
Learning: Matt implemented a cryptographic hash in webhook callback URLs using HMAC-SHA256 with the API key as the secret to prevent unauthorized completion of waitpoints in the Trigger.dev platform.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerByTaskAndWait()` to batch trigger tasks by passing task instances and wait for results
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.batchTrigger()` to trigger multiple runs of a task from inside another task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.batchTriggerAndWait()` to batch trigger tasks and wait for all results from a parent task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `idempotencyKeyTTL` option to define a time window during which duplicate triggers return the original run
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Subscribe to run updates using `runs.subscribeToRun()` for realtime monitoring of task execution
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `tasks.batchTrigger()` to trigger multiple runs of a single task with different payloads
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Control concurrency using the `queue` property with `concurrencyLimit` option
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.trigger()` to trigger multiple different tasks at once from backend code
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task duration using the `maxDuration` property (in seconds)
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `runs.subscribeToBatch()` to subscribe to changes for all runs in a batch
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `runs.subscribeToRunsWithTag()` to subscribe to all runs with a specific tag
Applied to files:
internal-packages/run-engine/README.md
🪛 LanguageTool
internal-packages/run-engine/README.md
[grammar] ~211-~211: Ensure spelling is correct
Context: ...A more advanced SDK which would require uses to explicitly create a waitpoint. We wo...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~211-~211: Ensure spelling is correct
Context: ...uld require uses to explicitly create a waitpoint. We would also need createWaitpoint()...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🪛 markdownlint-cli2 (0.21.0)
internal-packages/run-engine/README.md
[warning] 24-24: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
| ### `wait.forWaitpoint(waitpointId)` | ||
| ### `wait.forToken(waitpointId)` | ||
|
|
||
| A more advanced SDK which would require uses to explicitly create a waitpoint. We would also need `createWaitpoint()`, `completeWaitpoint()`, and `failWaitpoint()`. |
Contributor
There was a problem hiding this comment.
Fix grammatical error.
"uses" should be "users" in "would require uses to explicitly create."
📝 Suggested fix
-A more advanced SDK which would require uses to explicitly create a waitpoint. We would also need `createWaitpoint()`, `completeWaitpoint()`, and `failWaitpoint()`.
+A more advanced SDK which would require users to explicitly create a waitpoint. We would also need `createWaitpoint()`, `completeWaitpoint()`, and `failWaitpoint()`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| A more advanced SDK which would require uses to explicitly create a waitpoint. We would also need `createWaitpoint()`, `completeWaitpoint()`, and `failWaitpoint()`. | |
| A more advanced SDK which would require users to explicitly create a waitpoint. We would also need `createWaitpoint()`, `completeWaitpoint()`, and `failWaitpoint()`. |
🧰 Tools
🪛 LanguageTool
[grammar] ~211-~211: Ensure spelling is correct
Context: ...A more advanced SDK which would require uses to explicitly create a waitpoint. We wo...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~211-~211: Ensure spelling is correct
Context: ...uld require uses to explicitly create a waitpoint. We would also need createWaitpoint()...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@internal-packages/run-engine/README.md` at line 211, Fix the grammatical typo
in the README sentence: change "uses" to "users" in the line that reads "A more
advanced SDK which would require uses to explicitly create a waitpoint." Update
the sentence that mentions createWaitpoint(), completeWaitpoint(), and
failWaitpoint() so it reads "...would require users to explicitly create a
waitpoint." to correct the grammar.
This file can be opened/edited with Monodraw
matt-aitken
force-pushed
the
runengine-readme
branch
from
65c9489 to
428b4c7
Compare
Comment on lines
132
to
137
|
|
||
| The execution state of a run is stored in the `TaskRunExecutionSnapshot` table in Postgres. This is separate from the `TaskRun` status which is exposed to users via the dashboard and API. | ||
|
|
||
|  | ||
|
|
||
| The `TaskRunExecutionSnapshot` `executionStatus` is used to determine the execution status and is internal to the run engine. It is a log of events that impact run execution – the data is used to execute the run. | ||
|
|
||
| A common pattern we use is to read the current state and check that the passed in `snapshotId` matches the current `snapshotId`. If it doesn't, we know that the state has moved on. In the case of a checkpoint coming in, we know we can just ignore it. |
Contributor
There was a problem hiding this comment.
🚩 Removed execution-states.png reference without inline replacement
The old README referenced  which showed the execution state machine. The new ASCII art diagram in the Overview section covers the high-level run lifecycle states (DELAYED, RUN_CREATED, QUEUED, SUSPENDED, PENDING_EXECUTING, EXECUTING, EXECUTING_WITH_WAITPOINTS, PENDING_CANCEL, FINISHED) but may not fully replace the detail that was in the execution-states.png (which was specifically about TaskRunExecutionSnapshot executionStatus transitions). The section at line 133-139 still discusses execution snapshots but no longer has an associated diagram.
(Refers to lines 131-139)
Was this helpful? React with 👍 or 👎 to provide feedback.
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (4)
internal-packages/run-engine/README.md (4)
24-24:⚠️ Potential issue | 🟡 MinorAdd a language tag to the ASCII fenced block.
Line 24 still opens a fenced block without a language, which triggers MD040 in markdown linting.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` at line 24, The README has a fenced code block opened with triple backticks but no language tag (causing MD040); edit the fenced block opening (the ``` line) and add an explicit language identifier such as ```text (or ```plain) so the ASCII block is annotated and the markdown linter error is resolved.
221-223:⚠️ Potential issue | 🟠 MajorFix invalid TypeScript example: duplicate
const waitpointdeclaration.Line 221 and Line 222 both declare
const waitpointin the same scope, which is invalid. Rename the second variable and update downstream references.#!/bin/bash # Read-only verification: confirm duplicate declaration in the README example sed -n '218,230p' internal-packages/run-engine/README.md | cat -nSuggested fix
const waitpoint = await wait.createToken({ idempotencyKey: `purchase-${payload.cart.id}` }); -const waitpoint = await wait.retrieveToken(waitpoint.id); +const retrievedToken = await wait.retrieveToken(waitpoint.id);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` around lines 221 - 223, The example incorrectly declares const waitpoint twice; change the second declaration used with wait.retrieveToken to a new name (e.g., retrievedWaitpoint) and update any downstream references in the README example to use that new identifier; specifically modify the lines using wait.createToken and wait.retrieveToken so the first result is kept as waitpoint and the second result is assigned to a different variable, and ensure subsequent mentions reference the new variable name.
151-151:⚠️ Potential issue | 🟡 MinorFix possessive typo (
it's→its).Line 151 should read “with its
region”.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` at line 151, Replace the possessive typo "it's" with "its" in the sentence that currently reads "A worker will call the Trigger.dev API with it's `region`." so the line reads "A worker will call the Trigger.dev API with its `region`."; locate the exact string "with it's `region`" in the README content and update it to "with its `region`".
211-211:⚠️ Potential issue | 🟡 MinorFix grammar typo (
uses→users).Line 211 currently says “require uses”; it should be “require users”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` at line 211, Fix the grammar typo in the README sentence that currently reads "require uses to explicitly create a waitpoint" by replacing "uses" with "users"; update the sentence containing the phrase "require uses to explicitly create a waitpoint" (the line that also mentions createWaitpoint(), completeWaitpoint(), and failWaitpoint()) so it reads "require users to explicitly create a waitpoint".
🧹 Nitpick comments (1)
internal-packages/run-engine/README.md (1)
145-147: Clarify Regions vs Worker Groups terminology in this section.Line 145 and Line 147 mix “Regions” and “worker groups” in the same flow. Consider explicitly stating whether this is a UI rename over the same underlying concept to avoid reader confusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal-packages/run-engine/README.md` around lines 145 - 147, The wording mixes "Regions" and "worker groups"; update the README so it explicitly states that the dashboard "Regions" page is the UI label for the same underlying concept called "worker groups" (or vice versa), e.g., change the text to "Regions (UI label for worker groups)" and clarify that the `region` parameter you can override when triggering runs maps to the `masterQueue` for that worker group, ensuring readers understand that `region` -> `masterQueue` routing determines which worker group pulls the run.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@internal-packages/run-engine/README.md`:
- Line 24: The README has a fenced code block opened with triple backticks but
no language tag (causing MD040); edit the fenced block opening (the ``` line)
and add an explicit language identifier such as ```text (or ```plain) so the
ASCII block is annotated and the markdown linter error is resolved.
- Around line 221-223: The example incorrectly declares const waitpoint twice;
change the second declaration used with wait.retrieveToken to a new name (e.g.,
retrievedWaitpoint) and update any downstream references in the README example
to use that new identifier; specifically modify the lines using wait.createToken
and wait.retrieveToken so the first result is kept as waitpoint and the second
result is assigned to a different variable, and ensure subsequent mentions
reference the new variable name.
- Line 151: Replace the possessive typo "it's" with "its" in the sentence that
currently reads "A worker will call the Trigger.dev API with it's `region`." so
the line reads "A worker will call the Trigger.dev API with its `region`.";
locate the exact string "with it's `region`" in the README content and update it
to "with its `region`".
- Line 211: Fix the grammar typo in the README sentence that currently reads
"require uses to explicitly create a waitpoint" by replacing "uses" with
"users"; update the sentence containing the phrase "require uses to explicitly
create a waitpoint" (the line that also mentions createWaitpoint(),
completeWaitpoint(), and failWaitpoint()) so it reads "require users to
explicitly create a waitpoint".
---
Nitpick comments:
In `@internal-packages/run-engine/README.md`:
- Around line 145-147: The wording mixes "Regions" and "worker groups"; update
the README so it explicitly states that the dashboard "Regions" page is the UI
label for the same underlying concept called "worker groups" (or vice versa),
e.g., change the text to "Regions (UI label for worker groups)" and clarify that
the `region` parameter you can override when triggering runs maps to the
`masterQueue` for that worker group, ensuring readers understand that `region`
-> `masterQueue` routing determines which worker group pulls the run.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 96a5dad3-3288-44bc-a1f8-7fd33dbb6f03
⛔ Files ignored due to path filters (1)
internal-packages/run-engine/execution-states.pngis excluded by!**/*.png
📒 Files selected for processing (2)
internal-packages/run-engine/README.mdinternal-packages/run-engine/runengine-diagram.monojson
📜 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). (27)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: sdk-compat / Bun Runtime
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
internal-packages/run-engine/README.md
🧠 Learnings (38)
📓 Common learnings
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-13T13:37:49.544Z
Learning: Applies to **/*.{ts,tsx} : Use Run Engine 2.0 (internal/run-engine) and redis-worker for all new work - avoid DEPRECATED zodworker (Graphile-worker wrapper)
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/`
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-11-27T16:26:58.661Z
Learning: Use the Run Engine 2.0 from `internal/run-engine` for new run lifecycle code in the webapp instead of the legacy run engine
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: All run lifecycle operations (triggering, completing, cancelling, etc.) should be performed through the singleton run engine instance in `app/v3/runEngine.server.ts` via service calls
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: internal-packages/database/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:17.177Z
Learning: New code should always target Prisma RunEngineVersion V2 (run-engine + redis-worker), not V1 (legacy MarQS + Graphile)
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: Use Redis for distributed locks and queues in the RunEngine system via `RunQueue` and `RunLocker` utilities
📚 Learning: 2026-03-13T13:37:49.544Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-13T13:37:49.544Z
Learning: Applies to **/*.{ts,tsx} : Use Run Engine 2.0 (internal/run-engine) and redis-worker for all new work - avoid DEPRECATED zodworker (Graphile-worker wrapper)
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use the Run Engine 2.0 from `internal/run-engine` for new run lifecycle code in the webapp instead of the legacy run engine
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:42:56.114Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: All run lifecycle operations (triggering, completing, cancelling, etc.) should be performed through the singleton run engine instance in `app/v3/runEngine.server.ts` via service calls
Applied to files:
internal-packages/run-engine/README.md
📚 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:
internal-packages/run-engine/README.md
📚 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/systems/**/*.ts : Integrate OpenTelemetry tracer and meter instrumentation in RunEngine systems for observability
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-10T12:44:19.869Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:19.869Z
Learning: In the triggerdotdev/trigger.dev repository, docs PRs are often written as companions to implementation PRs (e.g., PR `#3200` documents features being added in PR `#3196`). When reviewing docs PRs, the documented features may exist in a companion/companion PR branch rather than main. Always check companion PRs referenced in the PR description before flagging missing implementations.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:43:02.539Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:02.539Z
Learning: Applies to docs/**/*.mdx : Use language tags in code fences: `typescript`, `bash`, `json`
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `trigger.dev/sdk/v3` for all imports in Trigger.dev tasks
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:43:48.124Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: packages/trigger-sdk/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:48.124Z
Learning: Applies to packages/trigger-sdk/**/*.{ts,tsx,js,jsx} : Always import from `trigger.dev/sdk`. Never use `trigger.dev/sdk/v3` (deprecated path alias)
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-13T13:37:49.544Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-13T13:37:49.544Z
Learning: Applies to **/*.{ts,tsx,js} : Always import from trigger.dev/sdk for Trigger.dev tasks - never use trigger.dev/sdk/v3 or deprecated client.defineJob
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:43:02.539Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:02.539Z
Learning: Applies to docs/**/*.mdx : Always import from `trigger.dev/sdk` in code examples (never from `trigger.dev/sdk/v3`)
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `task()` function from `trigger.dev/sdk/v3` to define tasks with id and run properties
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:26:37.432Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-27T16:26:37.432Z
Learning: Applies to packages/trigger-sdk/**/*.{ts,tsx} : In the Trigger.dev SDK (packages/trigger-sdk), prefer isomorphic code like fetch and ReadableStream instead of Node.js-specific code
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `schemaTask()` from `trigger.dev/sdk/v3` with Zod schema for payload validation
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:43:34.140Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: packages/cli-v3/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:34.140Z
Learning: Applies to packages/cli-v3/.claude/skills/trigger-dev-tasks/**/* : Update `.claude/skills/trigger-dev-tasks/` in parallel with `rules/` when SDK features change
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:43:37.906Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: packages/core/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:37.906Z
Learning: Applies to packages/core/**/*.{ts,tsx,js,jsx} : Never import the root package (trigger.dev/core). Always use subpath imports such as trigger.dev/core/v3, trigger.dev/core/v3/utils, trigger.dev/core/logger, or trigger.dev/core/schemas
Applied to files:
internal-packages/run-engine/README.md
📚 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/**/*.{ts,tsx} : When importing from `trigger.dev/core` in the webapp, use subpath exports from the package.json instead of importing from the root path
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use Redis for distributed locks and queues in the RunEngine system via `RunQueue` and `RunLocker` utilities
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-03-02T12:42:56.114Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: apps/webapp/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:42:56.114Z
Learning: Applies to apps/webapp/app/v3/*Worker.server.ts : New background job workers should use `trigger.dev/redis-worker` (e.g., `commonWorker.server.ts`, `alertsWorker.server.ts`, `batchTriggerWorker.server.ts`), not zodworker or graphile-worker
Applied to files:
internal-packages/run-engine/README.md
📚 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: Use `trigger.dev/redis-worker` for background job and worker system needs in the webapp and run engine
Applied to files:
internal-packages/run-engine/README.md
📚 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/**/*@(job|queue|worker|background).{ts,tsx} : Use trigger.dev/redis-worker for all new background job implementations, replacing graphile-worker and zodworker
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-07-18T12:50:37.351Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2277
File: apps/webapp/app/presenters/v3/VersionListPresenter.server.ts:62-65
Timestamp: 2025-07-18T12:50:37.351Z
Learning: Background workers don't share versions in the trigger.dev system, meaning each backgroundWorker record has a unique version field, so DISTINCT clauses are not needed when querying for versions.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2026-02-25T17:28:20.456Z
Learnt from: isshaddad
Repo: triggerdotdev/trigger.dev PR: 3130
File: docs/v3-openapi.yaml:3134-3135
Timestamp: 2026-02-25T17:28:20.456Z
Learning: In the Trigger.dev codebase, the `publicAccessToken` returned by the SDK's `wait.createToken()` method is not part of the HTTP response body from `POST /api/v1/waitpoints/tokens`. The server returns only `{ id, isCached, url }`. The SDK's `prepareData` hook generates the JWT client-side from the `x-trigger-jwt-claims` response header after the HTTP call completes. The OpenAPI spec correctly documents only the HTTP response body, not SDK transformations.
<!-- [/add_learning]
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.triggerAndWait()` to trigger a task and wait for its result from a parent task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerAndWait()` to batch trigger multiple different tasks and wait for results
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-05-07T09:59:03.771Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2025
File: apps/webapp/app/routes/api.v1.waitpoints.http-callback.$waitpointFriendlyId.callback.ts:0-0
Timestamp: 2025-05-07T09:59:03.771Z
Learning: Matt implemented a cryptographic hash in webhook callback URLs using HMAC-SHA256 with the API key as the secret to prevent unauthorized completion of waitpoints in the Trigger.dev platform.
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerByTaskAndWait()` to batch trigger tasks by passing task instances and wait for results
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.batchTrigger()` to trigger multiple runs of a task from inside another task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.batchTriggerAndWait()` to batch trigger tasks and wait for all results from a parent task
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `idempotencyKeyTTL` option to define a time window during which duplicate triggers return the original run
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Subscribe to run updates using `runs.subscribeToRun()` for realtime monitoring of task execution
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `tasks.batchTrigger()` to trigger multiple runs of a single task with different payloads
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Control concurrency using the `queue` property with `concurrencyLimit` option
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.trigger()` to trigger multiple different tasks at once from backend code
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task duration using the `maxDuration` property (in seconds)
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `runs.subscribeToBatch()` to subscribe to changes for all runs in a batch
Applied to files:
internal-packages/run-engine/README.md
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `runs.subscribeToRunsWithTag()` to subscribe to all runs with a specific tag
Applied to files:
internal-packages/run-engine/README.md
🪛 LanguageTool
internal-packages/run-engine/README.md
[grammar] ~211-~211: Ensure spelling is correct
Context: ...A more advanced SDK which would require uses to explicitly create a waitpoint. We wo...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~211-~211: Ensure spelling is correct
Context: ...uld require uses to explicitly create a waitpoint. We would also need createWaitpoint()...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🪛 markdownlint-cli2 (0.21.0)
internal-packages/run-engine/README.md
[warning] 24-24: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
samejr
approved these changes
Mar 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.