v4: simplified release concurrency system and status changes #2284
Conversation
…eases all the time
…rencyOnWaitpoint column
Also removed deadlock detection, and added environment burst concurrency
Cleaned up the API run statuses, including now detecting new clients and not breaking older clients by adding an API version header to all requests
🦋 Changeset detectedLatest commit: c16d8e8 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThis update removes the "release concurrency" feature and all related configuration, options, and code paths from the system. It eliminates references to Estimated code review effort5 (>120 minutes) 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🔭 Outside diff range comments (1)
internal-packages/run-engine/src/run-queue/index.ts (1)
404-439: Method name doesn't match its new behaviorThe method
currentConcurrencyOfQueuesnow tracks dequeued counts rather than general concurrency. Consider renaming this method tocurrentDequeuedOfQueuesto accurately reflect what it's measuring.
🧹 Nitpick comments (5)
apps/webapp/app/presenters/v3/QueueRetrievePresenter.server.ts (1)
108-120: LGTM: Backward compatibility maintained during feature removal.The approach of hardcoding
releaseConcurrencyOnWaitpoint: truewhile extending theQueueItemtype is a sensible way to maintain API compatibility during the transition away from the release concurrency feature. The TODO comment appropriately flags this as temporary.However, consider creating a tracking issue for the TODO to ensure this backward compatibility shim is eventually removed when all clients have been updated.
Would you like me to create a tracking issue for removing the
releaseConcurrencyOnWaitpointbackward compatibility shim?.changeset/little-birds-appear.md (1)
26-26: Fix grammatical error.-- `TIMED_OUT`: Task has reached it's maxDuration and has been stopped +- `TIMED_OUT`: Task has reached its maxDuration and has been stoppedinternal-packages/run-engine/src/engine/systems/waitpointSystem.ts (1)
524-524: Remove unused field selection.The
concurrencyLimitBurstFactoris selected but not used in this method.id: true, type: true, maximumConcurrencyLimit: true, - concurrencyLimitBurstFactor: true, project: { select: { id: true } }, organization: { select: { id: true } },internal-packages/run-engine/src/run-queue/keyProducer.ts (1)
69-89: Consider reducing code duplicationThe
envConcurrencyLimitBurstFactorKeymethod has nearly identical logic toenvConcurrencyLimitKey. Consider extracting a common helper method to reduce duplication.+ private envKeyWithSuffix( + envOrDescriptor: EnvDescriptor | RunQueueKeyProducerEnvironment, + suffix: string + ): string { + if ("id" in envOrDescriptor) { + return [ + this.orgKeySection(envOrDescriptor.organization.id), + this.projKeySection(envOrDescriptor.project.id), + this.envKeySection(envOrDescriptor.id), + suffix, + ].join(":"); + } else { + return [ + this.orgKeySection(envOrDescriptor.orgId), + this.projKeySection(envOrDescriptor.projectId), + this.envKeySection(envOrDescriptor.envId), + suffix, + ].join(":"); + } + } envConcurrencyLimitBurstFactorKey(env: EnvDescriptor): string; envConcurrencyLimitBurstFactorKey(env: RunQueueKeyProducerEnvironment): string; envConcurrencyLimitBurstFactorKey( envOrDescriptor: EnvDescriptor | RunQueueKeyProducerEnvironment ): string { - if ("id" in envOrDescriptor) { - return [ - this.orgKeySection(envOrDescriptor.organization.id), - this.projKeySection(envOrDescriptor.project.id), - this.envKeySection(envOrDescriptor.id), - constants.CONCURRENCY_LIMIT_BURST_FACTOR_PART, - ].join(":"); - } else { - return [ - this.orgKeySection(envOrDescriptor.orgId), - this.projKeySection(envOrDescriptor.projectId), - this.envKeySection(envOrDescriptor.envId), - constants.CONCURRENCY_LIMIT_BURST_FACTOR_PART, - ].join(":"); - } + return this.envKeyWithSuffix(envOrDescriptor, constants.CONCURRENCY_LIMIT_BURST_FACTOR_PART); }apps/webapp/app/services/realtimeClient.server.ts (1)
451-468: Consider performance and edge cases in response rewritingThe current implementation reads the entire response body into memory and uses global string replacement. Consider:
- This could be memory-intensive for large responses
- The regex replacement might match unintended occurrences in user data
Consider using a streaming JSON parser or more targeted replacement that only affects the status field in the expected JSON structure.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (5)
references/hello-world/src/trigger/deadlocks.tsis excluded by!references/**references/hello-world/src/trigger/example.tsis excluded by!references/**references/hello-world/src/trigger/realtime.tsis excluded by!references/**references/hello-world/src/trigger/release-concurrency.tsis excluded by!references/**references/hello-world/src/trigger/waits.tsis excluded by!references/**
📒 Files selected for processing (90)
.changeset/little-birds-appear.md(1 hunks)apps/webapp/app/api/versions.ts(1 hunks)apps/webapp/app/components/runs/v3/RunFilters.tsx(1 hunks)apps/webapp/app/components/runs/v3/TaskRunStatus.tsx(7 hunks)apps/webapp/app/database-types.ts(1 hunks)apps/webapp/app/env.server.ts(1 hunks)apps/webapp/app/models/taskRun.server.ts(1 hunks)apps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts(14 hunks)apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts(9 hunks)apps/webapp/app/presenters/v3/QueueListPresenter.server.ts(0 hunks)apps/webapp/app/presenters/v3/QueueRetrievePresenter.server.ts(2 hunks)apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx(1 hunks)apps/webapp/app/routes/api.v1.projects.$projectRef.runs.ts(1 hunks)apps/webapp/app/routes/api.v1.runs.$runParam.reschedule.ts(2 hunks)apps/webapp/app/routes/api.v1.runs.ts(1 hunks)apps/webapp/app/routes/api.v3.runs.$runId.ts(1 hunks)apps/webapp/app/routes/engine.v1.runs.$runFriendlyId.wait.duration.ts(0 hunks)apps/webapp/app/routes/engine.v1.runs.$runFriendlyId.waitpoints.tokens.$waitpointFriendlyId.wait.ts(1 hunks)apps/webapp/app/routes/realtime.v1.batches.$batchId.ts(1 hunks)apps/webapp/app/routes/realtime.v1.runs.$runId.ts(1 hunks)apps/webapp/app/routes/realtime.v1.runs.ts(1 hunks)apps/webapp/app/routes/realtime.v2.streams.$runId.$streamId.ts(0 hunks)apps/webapp/app/routes/resources.taskruns.$runParam.debug.ts(2 hunks)apps/webapp/app/runEngine/concerns/idempotencyKeys.server.ts(0 hunks)apps/webapp/app/runEngine/concerns/runChainStates.server.ts(0 hunks)apps/webapp/app/runEngine/services/triggerTask.server.ts(0 hunks)apps/webapp/app/runEngine/types.ts(0 hunks)apps/webapp/app/services/realtime/databaseRealtimeStreams.server.ts(0 hunks)apps/webapp/app/services/realtime/v2StreamsGlobal.server.ts(0 hunks)apps/webapp/app/services/realtimeClient.server.ts(10 hunks)apps/webapp/app/services/routeBuilders/apiBuilder.server.ts(5 hunks)apps/webapp/app/v3/runEngine.server.ts(1 hunks)apps/webapp/app/v3/services/alerts/deliverAlert.server.ts(3 hunks)apps/webapp/app/v3/services/createBackgroundWorker.server.ts(0 hunks)apps/webapp/app/v3/services/pauseQueue.server.ts(0 hunks)apps/webapp/app/v3/services/triggerTask.server.ts(0 hunks)apps/webapp/app/v3/taskRunHeartbeatFailed.server.ts(1 hunks)apps/webapp/app/v3/tracing.server.ts(2 hunks)apps/webapp/test/engine/triggerTask.test.ts(0 hunks)apps/webapp/test/realtimeClient.test.ts(10 hunks)internal-packages/database/prisma/migrations/20250715124534_add_concurrency_limit_burst_factor_to_runtime_environment/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250716145327_drop_release_concurrency_on_waitpoint_on_task_queue/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250716150513_add_dequeued_task_run_status/migration.sql(1 hunks)internal-packages/database/prisma/schema.prisma(2 hunks)internal-packages/database/src/transaction.ts(1 hunks)internal-packages/run-engine/src/engine/index.ts(2 hunks)internal-packages/run-engine/src/engine/releaseConcurrencyTokenBucketQueue.ts(0 hunks)internal-packages/run-engine/src/engine/statuses.ts(0 hunks)internal-packages/run-engine/src/engine/systems/checkpointSystem.ts(3 hunks)internal-packages/run-engine/src/engine/systems/dequeueSystem.ts(1 hunks)internal-packages/run-engine/src/engine/systems/releaseConcurrencySystem.ts(0 hunks)internal-packages/run-engine/src/engine/systems/runAttemptSystem.ts(1 hunks)internal-packages/run-engine/src/engine/systems/waitpointSystem.ts(3 hunks)internal-packages/run-engine/src/engine/tests/checkpoints.test.ts(0 hunks)internal-packages/run-engine/src/engine/tests/releaseConcurrency.test.ts(0 hunks)internal-packages/run-engine/src/engine/tests/releaseConcurrencyTokenBucketQueue.test.ts(0 hunks)internal-packages/run-engine/src/engine/tests/setup.ts(3 hunks)internal-packages/run-engine/src/engine/tests/utils/engineTest.ts(0 hunks)internal-packages/run-engine/src/engine/tests/waitpoints.test.ts(0 hunks)internal-packages/run-engine/src/engine/types.ts(2 hunks)internal-packages/run-engine/src/run-queue/fairQueueSelectionStrategy.ts(2 hunks)internal-packages/run-engine/src/run-queue/index.test.ts(3 hunks)internal-packages/run-engine/src/run-queue/index.ts(42 hunks)internal-packages/run-engine/src/run-queue/keyProducer.ts(9 hunks)internal-packages/run-engine/src/run-queue/tests/ack.test.ts(2 hunks)internal-packages/run-engine/src/run-queue/tests/concurrencySweeper.test.ts(2 hunks)internal-packages/run-engine/src/run-queue/tests/dequeueMessageFromWorkerQueue.test.ts(3 hunks)internal-packages/run-engine/src/run-queue/tests/enqueueMessage.test.ts(2 hunks)internal-packages/run-engine/src/run-queue/tests/fairQueueSelectionStrategy.test.ts(4 hunks)internal-packages/run-engine/src/run-queue/tests/keyProducer.test.ts(6 hunks)internal-packages/run-engine/src/run-queue/tests/nack.test.ts(2 hunks)internal-packages/run-engine/src/run-queue/tests/reacquireConcurrency.test.ts(0 hunks)internal-packages/run-engine/src/run-queue/tests/releaseConcurrency.test.ts(2 hunks)internal-packages/run-engine/src/run-queue/types.ts(4 hunks)internal-packages/run-engine/src/shared/index.ts(1 hunks)internal-packages/testcontainers/src/utils.ts(2 hunks)packages/core/src/v3/apiClient/index.ts(2 hunks)packages/core/src/v3/apiClient/runStream.ts(5 hunks)packages/core/src/v3/apiClient/stream.ts(2 hunks)packages/core/src/v3/apiClient/version.ts(1 hunks)packages/core/src/v3/resource-catalog/standardResourceCatalog.ts(1 hunks)packages/core/src/v3/schemas/api.ts(2 hunks)packages/core/src/v3/schemas/queues.ts(0 hunks)packages/core/src/v3/schemas/runEngine.ts(1 hunks)packages/core/src/v3/schemas/schemas.ts(0 hunks)packages/core/src/v3/serverOnly/index.ts(1 hunks)packages/core/src/v3/types/queues.ts(0 hunks)packages/core/src/v3/types/tasks.ts(1 hunks)packages/trigger-sdk/src/v3/shared.ts(0 hunks)packages/trigger-sdk/src/v3/wait.ts(1 hunks)
💤 Files with no reviewable changes (26)
- apps/webapp/app/routes/engine.v1.runs.$runFriendlyId.wait.duration.ts
- packages/core/src/v3/schemas/queues.ts
- apps/webapp/app/runEngine/concerns/idempotencyKeys.server.ts
- apps/webapp/app/presenters/v3/QueueListPresenter.server.ts
- packages/core/src/v3/schemas/schemas.ts
- packages/core/src/v3/types/queues.ts
- internal-packages/run-engine/src/engine/statuses.ts
- apps/webapp/app/v3/services/pauseQueue.server.ts
- apps/webapp/app/v3/services/triggerTask.server.ts
- apps/webapp/app/runEngine/services/triggerTask.server.ts
- packages/trigger-sdk/src/v3/shared.ts
- apps/webapp/app/runEngine/types.ts
- apps/webapp/app/v3/services/createBackgroundWorker.server.ts
- internal-packages/run-engine/src/engine/tests/utils/engineTest.ts
- apps/webapp/app/routes/realtime.v2.streams.$runId.$streamId.ts
- internal-packages/run-engine/src/engine/tests/waitpoints.test.ts
- internal-packages/run-engine/src/engine/tests/checkpoints.test.ts
- apps/webapp/test/engine/triggerTask.test.ts
- internal-packages/run-engine/src/run-queue/tests/reacquireConcurrency.test.ts
- apps/webapp/app/services/realtime/databaseRealtimeStreams.server.ts
- internal-packages/run-engine/src/engine/systems/releaseConcurrencySystem.ts
- internal-packages/run-engine/src/engine/tests/releaseConcurrencyTokenBucketQueue.test.ts
- internal-packages/run-engine/src/engine/tests/releaseConcurrency.test.ts
- apps/webapp/app/runEngine/concerns/runChainStates.server.ts
- internal-packages/run-engine/src/engine/releaseConcurrencyTokenBucketQueue.ts
- apps/webapp/app/services/realtime/v2StreamsGlobal.server.ts
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
For TypeScript, we usually use types over interfaces
Avoid enums
No default exports, use function declarations
Files:
internal-packages/run-engine/src/run-queue/tests/enqueueMessage.test.tsapps/webapp/app/routes/realtime.v1.runs.$runId.tsapps/webapp/app/models/taskRun.server.tsapps/webapp/app/v3/services/alerts/deliverAlert.server.tspackages/core/src/v3/schemas/runEngine.tspackages/core/src/v3/serverOnly/index.tsinternal-packages/run-engine/src/run-queue/tests/releaseConcurrency.test.tsapps/webapp/app/routes/realtime.v1.batches.$batchId.tspackages/core/src/v3/apiClient/stream.tspackages/core/src/v3/apiClient/version.tsapps/webapp/app/routes/engine.v1.runs.$runFriendlyId.waitpoints.tokens.$waitpointFriendlyId.wait.tsapps/webapp/app/routes/realtime.v1.runs.tsapps/webapp/app/routes/api.v1.runs.$runParam.reschedule.tsinternal-packages/database/src/transaction.tsinternal-packages/run-engine/src/engine/systems/runAttemptSystem.tsapps/webapp/app/routes/api.v1.runs.tsapps/webapp/app/database-types.tsapps/webapp/app/routes/api.v3.runs.$runId.tsinternal-packages/run-engine/src/shared/index.tsinternal-packages/run-engine/src/run-queue/tests/concurrencySweeper.test.tsinternal-packages/run-engine/src/run-queue/tests/ack.test.tsapps/webapp/app/routes/resources.taskruns.$runParam.debug.tsapps/webapp/app/env.server.tsapps/webapp/app/services/routeBuilders/apiBuilder.server.tsinternal-packages/run-engine/src/run-queue/tests/nack.test.tsapps/webapp/app/v3/runEngine.server.tsinternal-packages/run-engine/src/run-queue/tests/keyProducer.test.tsapps/webapp/app/v3/taskRunHeartbeatFailed.server.tsapps/webapp/app/components/runs/v3/RunFilters.tsxpackages/core/src/v3/types/tasks.tsinternal-packages/run-engine/src/run-queue/index.test.tsinternal-packages/run-engine/src/engine/types.tsinternal-packages/testcontainers/src/utils.tsinternal-packages/run-engine/src/run-queue/tests/fairQueueSelectionStrategy.test.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsxpackages/core/src/v3/apiClient/index.tsinternal-packages/run-engine/src/engine/tests/setup.tsinternal-packages/run-engine/src/engine/systems/checkpointSystem.tsapps/webapp/app/routes/api.v1.projects.$projectRef.runs.tsapps/webapp/app/v3/tracing.server.tspackages/core/src/v3/resource-catalog/standardResourceCatalog.tsapps/webapp/app/presenters/v3/QueueRetrievePresenter.server.tspackages/trigger-sdk/src/v3/wait.tspackages/core/src/v3/schemas/api.tsinternal-packages/run-engine/src/run-queue/tests/dequeueMessageFromWorkerQueue.test.tsinternal-packages/run-engine/src/engine/systems/dequeueSystem.tsapps/webapp/app/components/runs/v3/TaskRunStatus.tsxapps/webapp/app/api/versions.tsapps/webapp/test/realtimeClient.test.tsinternal-packages/run-engine/src/engine/index.tsapps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.tsinternal-packages/run-engine/src/run-queue/fairQueueSelectionStrategy.tsinternal-packages/run-engine/src/run-queue/types.tsinternal-packages/run-engine/src/run-queue/index.tsinternal-packages/run-engine/src/engine/systems/waitpointSystem.tsinternal-packages/run-engine/src/run-queue/keyProducer.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.tspackages/core/src/v3/apiClient/runStream.tsapps/webapp/app/services/realtimeClient.server.ts
**/*.test.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Our tests are all vitest
Files:
internal-packages/run-engine/src/run-queue/tests/enqueueMessage.test.tsinternal-packages/run-engine/src/run-queue/tests/releaseConcurrency.test.tsinternal-packages/run-engine/src/run-queue/tests/concurrencySweeper.test.tsinternal-packages/run-engine/src/run-queue/tests/ack.test.tsinternal-packages/run-engine/src/run-queue/tests/nack.test.tsinternal-packages/run-engine/src/run-queue/tests/keyProducer.test.tsinternal-packages/run-engine/src/run-queue/index.test.tsinternal-packages/run-engine/src/run-queue/tests/fairQueueSelectionStrategy.test.tsinternal-packages/run-engine/src/run-queue/tests/dequeueMessageFromWorkerQueue.test.tsapps/webapp/test/realtimeClient.test.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
We use zod a lot in packages/core and in the webapp
Files:
apps/webapp/app/routes/realtime.v1.runs.$runId.tsapps/webapp/app/models/taskRun.server.tsapps/webapp/app/v3/services/alerts/deliverAlert.server.tspackages/core/src/v3/schemas/runEngine.tspackages/core/src/v3/serverOnly/index.tsapps/webapp/app/routes/realtime.v1.batches.$batchId.tspackages/core/src/v3/apiClient/stream.tspackages/core/src/v3/apiClient/version.tsapps/webapp/app/routes/engine.v1.runs.$runFriendlyId.waitpoints.tokens.$waitpointFriendlyId.wait.tsapps/webapp/app/routes/realtime.v1.runs.tsapps/webapp/app/routes/api.v1.runs.$runParam.reschedule.tsapps/webapp/app/routes/api.v1.runs.tsapps/webapp/app/database-types.tsapps/webapp/app/routes/api.v3.runs.$runId.tsapps/webapp/app/routes/resources.taskruns.$runParam.debug.tsapps/webapp/app/env.server.tsapps/webapp/app/services/routeBuilders/apiBuilder.server.tsapps/webapp/app/v3/runEngine.server.tsapps/webapp/app/v3/taskRunHeartbeatFailed.server.tsapps/webapp/app/components/runs/v3/RunFilters.tsxpackages/core/src/v3/types/tasks.tsapps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsxpackages/core/src/v3/apiClient/index.tsapps/webapp/app/routes/api.v1.projects.$projectRef.runs.tsapps/webapp/app/v3/tracing.server.tspackages/core/src/v3/resource-catalog/standardResourceCatalog.tsapps/webapp/app/presenters/v3/QueueRetrievePresenter.server.tspackages/core/src/v3/schemas/api.tsapps/webapp/app/components/runs/v3/TaskRunStatus.tsxapps/webapp/app/api/versions.tsapps/webapp/test/realtimeClient.test.tsapps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.tspackages/core/src/v3/apiClient/runStream.tsapps/webapp/app/services/realtimeClient.server.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: In the webapp, all environment variables must be accessed through theenvexport ofenv.server.ts, instead of directly accessingprocess.env.
When importing from@trigger.dev/corein the webapp, never import from the root@trigger.dev/corepath; always use one of the subpath exports as defined in the package's package.json.
Files:
apps/webapp/app/routes/realtime.v1.runs.$runId.tsapps/webapp/app/models/taskRun.server.tsapps/webapp/app/v3/services/alerts/deliverAlert.server.tsapps/webapp/app/routes/realtime.v1.batches.$batchId.tsapps/webapp/app/routes/engine.v1.runs.$runFriendlyId.waitpoints.tokens.$waitpointFriendlyId.wait.tsapps/webapp/app/routes/realtime.v1.runs.tsapps/webapp/app/routes/api.v1.runs.$runParam.reschedule.tsapps/webapp/app/routes/api.v1.runs.tsapps/webapp/app/database-types.tsapps/webapp/app/routes/api.v3.runs.$runId.tsapps/webapp/app/routes/resources.taskruns.$runParam.debug.tsapps/webapp/app/env.server.tsapps/webapp/app/services/routeBuilders/apiBuilder.server.tsapps/webapp/app/v3/runEngine.server.tsapps/webapp/app/v3/taskRunHeartbeatFailed.server.tsapps/webapp/app/components/runs/v3/RunFilters.tsxapps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsxapps/webapp/app/routes/api.v1.projects.$projectRef.runs.tsapps/webapp/app/v3/tracing.server.tsapps/webapp/app/presenters/v3/QueueRetrievePresenter.server.tsapps/webapp/app/components/runs/v3/TaskRunStatus.tsxapps/webapp/app/api/versions.tsapps/webapp/test/realtimeClient.test.tsapps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.tsapps/webapp/app/presenters/v3/ApiRunListPresenter.server.tsapps/webapp/app/services/realtimeClient.server.ts
internal-packages/database/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
We use prisma in internal-packages/database for our database interactions using PostgreSQL
Files:
internal-packages/database/src/transaction.ts
apps/webapp/app/services/**/*.server.ts
📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
For testable services, separate service logic and configuration, as exemplified by
realtimeClient.server.ts(service) andrealtimeClientGlobal.server.ts(configuration).
Files:
apps/webapp/app/services/routeBuilders/apiBuilder.server.tsapps/webapp/app/services/realtimeClient.server.ts
🧠 Learnings (57)
internal-packages/database/prisma/migrations/20250716145327_drop_release_concurrency_on_waitpoint_on_task_queue/migration.sql (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
internal-packages/run-engine/src/run-queue/tests/enqueueMessage.test.ts (8)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
apps/webapp/app/routes/realtime.v1.runs.$runId.ts (3)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
internal-packages/database/prisma/migrations/20250716150513_add_dequeued_task_run_status/migration.sql (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
internal-packages/database/prisma/migrations/20250715124534_add_concurrency_limit_burst_factor_to_runtime_environment/migration.sql (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: ericallam
PR: #2086
File: internal-packages/database/prisma/migrations/20250511145836_runtime_environment_add_is_branchable_environment/migration.sql:1-3
Timestamp: 2025-05-27T19:30:34.004Z
Learning: In modern PostgreSQL versions (11+), adding a column with a constant default value (like DEFAULT false, DEFAULT 0, DEFAULT 'text') does NOT require a table rewrite. PostgreSQL stores the default value in the catalog and applies it virtually when reading rows. Only non-constant defaults or more complex scenarios require table rewrites. Avoid suggesting multi-step migrations for simple constant defaults.
apps/webapp/app/models/taskRun.server.ts (5)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from inside another task, use yourTask.trigger, yourTask.batchTrigger, yourTask.triggerAndWait, yourTask.batchTriggerAndWait, batch.triggerAndWait, batch.triggerByTask, or batch.triggerByTaskAndWait as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
apps/webapp/app/v3/services/alerts/deliverAlert.server.ts (11)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using lifecycle hooks (init, cleanup, onStart, onSuccess, onFailure, handleError), implement them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
packages/core/src/v3/schemas/runEngine.ts (1)
Learnt from: nicktrn
PR: #1418
File: packages/core/src/v3/errors.ts:364-371
Timestamp: 2024-10-18T15:41:52.352Z
Learning: In packages/core/src/v3/errors.ts, within the taskRunErrorEnhancer function, error.message is always defined, so it's safe to directly call error.message.includes("SIGTERM") without additional checks.
packages/core/src/v3/serverOnly/index.ts (6)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.{ts,tsx} : No default exports, use function declarations
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/services/**/*.server.ts : For testable services, separate service logic and configuration, as exemplified by realtimeClient.server.ts (service) and realtimeClientGlobal.server.ts (configuration).
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST export every task, including subtasks, in Trigger.dev task files.
internal-packages/run-engine/src/run-queue/tests/releaseConcurrency.test.ts (7)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Build extensions such as additionalFiles, additionalPackages, aptGet, emitDecoratorMetadata, prismaExtension, syncEnvVars, puppeteer, ffmpeg, and esbuildPlugin must be configured in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
apps/webapp/app/routes/realtime.v1.batches.$batchId.ts (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
packages/core/src/v3/apiClient/version.ts (5)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : The trigger.config.ts file must use defineConfig from @trigger.dev/sdk/v3 and follow the configuration structure shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST export every task, including subtasks, in Trigger.dev task files.
apps/webapp/app/routes/realtime.v1.runs.ts (3)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
apps/webapp/app/routes/api.v1.runs.$runParam.reschedule.ts (7)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
internal-packages/database/src/transaction.ts (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
internal-packages/run-engine/src/engine/systems/runAttemptSystem.ts (7)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using lifecycle hooks (init, cleanup, onStart, onSuccess, onFailure, handleError), implement them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
apps/webapp/app/routes/api.v1.runs.ts (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
apps/webapp/app/database-types.ts (1)
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
apps/webapp/app/routes/api.v3.runs.$runId.ts (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
internal-packages/run-engine/src/run-queue/tests/concurrencySweeper.test.ts (9)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
internal-packages/run-engine/src/run-queue/tests/ack.test.ts (6)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
apps/webapp/app/routes/resources.taskruns.$runParam.debug.ts (4)
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: ericallam
PR: #2175
File: apps/webapp/app/services/environmentMetricsRepository.server.ts:202-207
Timestamp: 2025-06-14T08:07:46.625Z
Learning: In apps/webapp/app/services/environmentMetricsRepository.server.ts, the ClickHouse methods (getTaskActivity, getCurrentRunningStats, getAverageDurations) intentionally do not filter by the tasks parameter at the ClickHouse level, even though the tasks parameter is accepted by the public methods. This is done on purpose as there is not much benefit from adding that filtering at the ClickHouse layer.
apps/webapp/app/env.server.ts (3)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
apps/webapp/app/services/routeBuilders/apiBuilder.server.ts (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to {packages/core,apps/webapp}/**/*.{ts,tsx} : We use zod a lot in packages/core and in the webapp
internal-packages/run-engine/src/run-queue/tests/nack.test.ts (6)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
apps/webapp/app/v3/runEngine.server.ts (4)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Build extensions such as additionalFiles, additionalPackages, aptGet, emitDecoratorMetadata, prismaExtension, syncEnvVars, puppeteer, ffmpeg, and esbuildPlugin must be configured in trigger.config.ts as shown.
internal-packages/run-engine/src/run-queue/tests/keyProducer.test.ts (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
apps/webapp/app/v3/taskRunHeartbeatFailed.server.ts (3)
Learnt from: nicktrn
PR: #1418
File: packages/core/src/v3/errors.ts:364-371
Timestamp: 2024-10-18T15:41:52.352Z
Learning: In packages/core/src/v3/errors.ts, within the taskRunErrorEnhancer function, error.message is always defined, so it's safe to directly call error.message.includes("SIGTERM") without additional checks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
apps/webapp/app/components/runs/v3/RunFilters.tsx (13)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using lifecycle hooks (init, cleanup, onStart, onSuccess, onFailure, handleError), implement them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST export every task, including subtasks, in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
packages/core/src/v3/types/tasks.ts (15)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from inside another task, use yourTask.trigger, yourTask.batchTrigger, yourTask.triggerAndWait, yourTask.batchTriggerAndWait, batch.triggerAndWait, batch.triggerByTask, or batch.triggerByTaskAndWait as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : NEVER generate deprecated code patterns using client.defineJob and related deprecated APIs, as shown in the prohibited code block.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Build extensions such as additionalFiles, additionalPackages, aptGet, emitDecoratorMetadata, prismaExtension, syncEnvVars, puppeteer, ffmpeg, and esbuildPlugin must be configured in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Each task needs a unique ID within your project.
internal-packages/run-engine/src/run-queue/index.test.ts (5)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
internal-packages/run-engine/src/engine/types.ts (8)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Build extensions such as additionalFiles, additionalPackages, aptGet, emitDecoratorMetadata, prismaExtension, syncEnvVars, puppeteer, ffmpeg, and esbuildPlugin must be configured in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : NEVER generate deprecated code patterns using client.defineJob and related deprecated APIs, as shown in the prohibited code block.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: nicktrn
PR: #1608
File: apps/webapp/app/v3/services/triggerTask.server.ts:418-418
Timestamp: 2025-01-13T18:31:48.160Z
Learning: The MachinePresetName schema is used to validate machine preset values in the trigger.dev codebase, ensuring type safety and validation of machine preset options.
internal-packages/database/prisma/schema.prisma (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
internal-packages/testcontainers/src/utils.ts (9)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/services/**/*.server.ts : For testable services, separate service logic and configuration, as exemplified by realtimeClient.server.ts (service) and realtimeClientGlobal.server.ts (configuration).
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.{ts,tsx} : No default exports, use function declarations
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.{ts,tsx} : Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to {packages/core,apps/webapp}/**/*.{ts,tsx} : We use zod a lot in packages/core and in the webapp
internal-packages/run-engine/src/run-queue/tests/fairQueueSelectionStrategy.test.ts (4)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
internal-packages/run-engine/src/engine/tests/setup.ts (12)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Build extensions such as additionalFiles, additionalPackages, aptGet, emitDecoratorMetadata, prismaExtension, syncEnvVars, puppeteer, ffmpeg, and esbuildPlugin must be configured in trigger.config.ts as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST NEVER use client.defineJob in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
internal-packages/run-engine/src/engine/systems/checkpointSystem.ts (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
apps/webapp/app/routes/api.v1.projects.$projectRef.runs.ts (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
apps/webapp/app/v3/tracing.server.ts (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
apps/webapp/app/presenters/v3/QueueRetrievePresenter.server.ts (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
packages/trigger-sdk/src/v3/wait.ts (4)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : NEVER generate deprecated code patterns using client.defineJob and related deprecated APIs, as shown in the prohibited code block.
Learnt from: matt-aitken
PR: #2025
File: internal-packages/database/prisma/schema.prisma:2103-2105
Timestamp: 2025-05-06T17:37:33.845Z
Learning: The resolver field in the Waitpoint model is used purely for filtering in the dashboard and doesn't change the underlying functionality of waitpoints. It provides additional classification (ENGINE, TOKEN, HTTP_CALLBACK) while the existing type field (MANUAL, DATETIME, etc.) continues to define the fundamental nature of the waitpoint.
packages/core/src/v3/schemas/api.ts (11)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Before generating any code for Trigger.dev tasks, verify: (1) Are you importing from @trigger.dev/sdk/v3? (2) Have you exported every task? (3) Have you generated any deprecated code patterns?
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Learnt from: matt-aitken
PR: #2025
File: internal-packages/database/prisma/schema.prisma:2103-2105
Timestamp: 2025-05-06T17:37:33.845Z
Learning: The resolver field in the Waitpoint model is used purely for filtering in the dashboard and doesn't change the underlying functionality of waitpoints. It provides additional classification (ENGINE, TOKEN, HTTP_CALLBACK) while the existing type field (MANUAL, DATETIME, etc.) continues to define the fundamental nature of the waitpoint.
internal-packages/run-engine/src/run-queue/tests/dequeueMessageFromWorkerQueue.test.ts (4)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
.changeset/little-birds-appear.md (5)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using idempotency, use the idempotencyKeys API and idempotencyKey/idempotencyKeyTTL options as shown.
internal-packages/run-engine/src/engine/systems/dequeueSystem.ts (1)
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
apps/webapp/app/components/runs/v3/TaskRunStatus.tsx (2)
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
apps/webapp/app/api/versions.ts (10)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to {packages/core,apps/webapp}/**/*.{ts,tsx} : We use zod a lot in packages/core and in the webapp
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : When importing from @trigger.dev/core in the webapp, never import from the root @trigger.dev/core path; always use one of the subpath exports as defined in the package's package.json.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
apps/webapp/test/realtimeClient.test.ts (15)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : NEVER generate deprecated code patterns using client.defineJob and related deprecated APIs, as shown in the prohibited code block.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/services/**/*.server.ts : For testable services, separate service logic and configuration, as exemplified by realtimeClient.server.ts (service) and realtimeClientGlobal.server.ts (configuration).
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching app/**/*.ts, and those files should not use environment variables directly; all configuration should be passed as options.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import env.server.ts, either directly or indirectly. Tests should only import classes and functions from files matching app/**/*.ts of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: nicktrn
PR: #2155
File: docs/docs.json:179-183
Timestamp: 2025-06-06T16:54:23.316Z
Learning: In the docs.json configuration for the Trigger.dev documentation (Mintlify system), both "tags": ["v4"] and "tag": "v4" properties can be used together and work correctly, even though this behavior is undocumented and may not work in local development environments.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : If you are able to generate an example payload for a task, do so.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using lifecycle hooks (init, cleanup, onStart, onSuccess, onFailure, handleError), implement them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
internal-packages/run-engine/src/engine/index.ts (3)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
apps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts (15)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Before generating any code for Trigger.dev tasks, verify: (1) Are you importing from @trigger.dev/sdk/v3? (2) Have you exported every task? (3) Have you generated any deprecated code patterns?
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : If you are able to generate an example payload for a task, do so.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from inside another task, use yourTask.trigger, yourTask.batchTrigger, yourTask.triggerAndWait, yourTask.batchTriggerAndWait, batch.triggerAndWait, batch.triggerByTask, or batch.triggerByTaskAndWait as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
internal-packages/run-engine/src/run-queue/types.ts (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
internal-packages/run-engine/src/run-queue/index.ts (10)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : NEVER generate deprecated code patterns using client.defineJob and related deprecated APIs, as shown in the prohibited code block.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST NEVER use client.defineJob in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: nicktrn
PR: #1387
File: packages/cli-v3/src/executions/taskRunProcess.ts:408-413
Timestamp: 2024-10-12T01:08:24.066Z
Learning: In the parseExecuteError method in packages/cli-v3/src/executions/taskRunProcess.ts, using String(error) to populate the message field works fine and even prepends error.name.
Learnt from: nicktrn
PR: #1387
File: packages/cli-v3/src/executions/taskRunProcess.ts:408-413
Timestamp: 2024-10-07T10:32:30.100Z
Learning: In the parseExecuteError method in packages/cli-v3/src/executions/taskRunProcess.ts, using String(error) to populate the message field works fine and even prepends error.name.
Learnt from: nicktrn
PR: #1418
File: packages/core/src/v3/errors.ts:364-371
Timestamp: 2024-10-18T15:41:52.352Z
Learning: In packages/core/src/v3/errors.ts, within the taskRunErrorEnhancer function, error.message is always defined, so it's safe to directly call error.message.includes("SIGTERM") without additional checks.
internal-packages/run-engine/src/engine/systems/waitpointSystem.ts (11)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from inside another task, use yourTask.trigger, yourTask.batchTrigger, yourTask.triggerAndWait, yourTask.batchTriggerAndWait, batch.triggerAndWait, batch.triggerByTask, or batch.triggerByTaskAndWait as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST NEVER use client.defineJob in Trigger.dev task files.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.458Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using lifecycle hooks (init, cleanup, onStart, onSuccess, onFailure, handleError), implement them as shown in the examples for Trigger.dev tasks.
internal-packages/run-engine/src/run-queue/keyProducer.ts (6)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in trigger.config.ts as shown.
Learnt from: nicktrn
PR: #2150
File: apps/supervisor/src/workloadManager/docker.ts:115-115
Timestamp: 2025-06-04T16:02:22.957Z
Learning: In the Trigger.dev codebase, the supervisor component uses DOCKER_ENFORCE_MACHINE_PRESETS while the docker provider component uses ENFORCE_MACHINE_PRESETS. These are separate components with separate environment variable configurations for the same logical concept of enforcing machine presets.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the env export of env.server.ts, instead of directly accessing process.env.
apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts (12)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/v3/presenters/**/*.server.ts : Favor the use of 'presenters' to move complex loader code into a class, as seen in app/v3/presenters/**/*.server.ts.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Do not use or add new code to the legacy run engine; focus on using and migrating to Run Engine 2.0 in @internal/run-engine.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : The run function contains your task logic in Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : You MUST use @trigger.dev/sdk/v3 when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the task function from @trigger.dev/sdk/v3 and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing schema tasks, use schemaTask from @trigger.dev/sdk/v3 and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use schedules.task from @trigger.dev/sdk/v3 and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using metadata in tasks, use the metadata API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When triggering a task from backend code, use tasks.trigger, tasks.batchTrigger, or tasks.triggerAndPoll as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
packages/core/src/v3/apiClient/runStream.ts (2)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
apps/webapp/app/services/realtimeClient.server.ts (4)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : When using Realtime features, use the runs.subscribeToRun, runs.subscribeToRunsWithTag, and runs.subscribeToBatch APIs as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.168Z
Learning: Applies to apps/webapp/app/services/**/*.server.ts : For testable services, separate service logic and configuration, as exemplified by realtimeClient.server.ts (service) and realtimeClientGlobal.server.ts (configuration).
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:24.984Z
Learning: Applies to /trigger//*.{ts,tsx,js,jsx} : NEVER generate deprecated code patterns using client.defineJob and related deprecated APIs, as shown in the prohibited code block.
Learnt from: matt-aitken
PR: #2264
File: apps/webapp/app/services/runsRepository.server.ts:172-174
Timestamp: 2025-07-12T18:06:04.133Z
Learning: In apps/webapp/app/services/runsRepository.server.ts, the in-memory status filtering after fetching runs from Prisma is intentionally used as a workaround for ClickHouse data delays. This approach is acceptable because the result set is limited to a maximum of 100 runs due to pagination, making the performance impact negligible.
🧬 Code Graph Analysis (20)
internal-packages/run-engine/src/run-queue/tests/enqueueMessage.test.ts (1)
internal-packages/database/src/transaction.ts (1)
Decimal(12-12)
apps/webapp/app/routes/realtime.v1.runs.$runId.ts (1)
apps/webapp/app/services/realtimeClientGlobal.server.ts (1)
realtimeClient(34-34)
apps/webapp/app/models/taskRun.server.ts (2)
apps/webapp/app/database-types.ts (1)
TaskRunStatus(29-47)packages/core/src/v3/schemas/runEngine.ts (2)
TaskRunStatus(21-39)TaskRunStatus(41-41)
apps/webapp/app/v3/services/alerts/deliverAlert.server.ts (3)
apps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts (1)
ApiRetrieveRunPresenter(67-406)apps/webapp/app/api/versions.ts (1)
CURRENT_API_VERSION(7-7)packages/core/src/v3/schemas/api.ts (2)
RunStatus(640-667)RunStatus(669-669)
internal-packages/run-engine/src/run-queue/tests/releaseConcurrency.test.ts (1)
internal-packages/database/src/transaction.ts (1)
Decimal(12-12)
apps/webapp/app/routes/realtime.v1.batches.$batchId.ts (1)
apps/webapp/app/services/realtimeClientGlobal.server.ts (1)
realtimeClient(34-34)
packages/core/src/v3/apiClient/stream.ts (1)
packages/core/src/v3/apiClient/version.ts (2)
API_VERSION_HEADER_NAME(2-2)API_VERSION(1-1)
apps/webapp/app/routes/realtime.v1.runs.ts (1)
apps/webapp/app/services/realtimeClientGlobal.server.ts (1)
realtimeClient(34-34)
apps/webapp/app/routes/api.v3.runs.$runId.ts (1)
apps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts (1)
ApiRetrieveRunPresenter(67-406)
internal-packages/run-engine/src/shared/index.ts (1)
internal-packages/run-engine/src/engine/tests/setup.ts (1)
AuthenticatedEnvironment(17-19)
internal-packages/run-engine/src/run-queue/tests/concurrencySweeper.test.ts (1)
internal-packages/database/src/transaction.ts (1)
Decimal(12-12)
internal-packages/run-engine/src/run-queue/tests/ack.test.ts (1)
internal-packages/database/src/transaction.ts (1)
Decimal(12-12)
apps/webapp/app/routes/resources.taskruns.$runParam.debug.ts (3)
internal-packages/run-engine/src/run-queue/keyProducer.ts (1)
queueCurrentConcurrencyKey(157-165)apps/webapp/app/v3/marqs/marqsKeyProducer.ts (1)
queueCurrentConcurrencyKey(128-136)apps/webapp/app/v3/runEngine.server.ts (1)
engine(9-9)
internal-packages/run-engine/src/run-queue/tests/nack.test.ts (1)
internal-packages/database/src/transaction.ts (1)
Decimal(12-12)
internal-packages/run-engine/src/run-queue/index.test.ts (1)
internal-packages/database/src/transaction.ts (1)
Decimal(12-12)
packages/core/src/v3/apiClient/index.ts (1)
packages/core/src/v3/apiClient/version.ts (2)
API_VERSION_HEADER_NAME(2-2)API_VERSION(1-1)
apps/webapp/app/presenters/v3/QueueRetrievePresenter.server.ts (1)
packages/core/src/v3/schemas/queues.ts (2)
QueueItem(16-35)QueueItem(37-37)
apps/webapp/app/api/versions.ts (1)
packages/core/src/v3/apiClient/version.ts (1)
API_VERSION_HEADER_NAME(2-2)
internal-packages/run-engine/src/run-queue/fairQueueSelectionStrategy.ts (1)
internal-packages/run-engine/src/run-queue/types.ts (1)
EnvDescriptor(43-47)
packages/core/src/v3/apiClient/runStream.ts (1)
packages/core/src/v3/schemas/api.ts (2)
RunStatus(640-667)RunStatus(669-669)
🪛 Biome (1.9.4)
apps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts
[error] 225-225: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 228-228: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
⏰ 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). (25)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: typecheck / typecheck
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (120)
internal-packages/testcontainers/src/utils.ts (2)
1-1: Import re-ordering looks goodMoving
createClientto the top clarifies third-party dependencies and removes the duplicate import later in the file. No functional impact.
12-12: Consolidated log helpers into a single importCombining the four symbols in one line reduces noise and keeps internal imports tidy.
internal-packages/database/src/transaction.ts (1)
12-12: LGTM! Clean export for burst factor support.The Decimal export from Prisma enables precise arithmetic for the new concurrency burst factor feature, following the established pattern of exporting database utilities from this module.
internal-packages/run-engine/src/run-queue/tests/releaseConcurrency.test.ts (2)
9-32: Verify consistency with release concurrency removal.This test file appears to still be testing release concurrency functionality (e.g.,
releaseAllConcurrencyon line 92), but the PR objectives state that the release concurrency feature has been removed. The AI summary also indicates this file was deleted.Please confirm if this file should still exist and be testing release concurrency methods, or if it needs to be updated/removed to align with the feature removal.
#!/bin/bash # Description: Check if releaseAllConcurrency method still exists in the RunQueue implementation # Expected: Method should be removed if release concurrency feature was eliminated # Search for releaseAllConcurrency method definition rg -A 10 "releaseAllConcurrency.*\(" --type ts # Also check for any remaining release concurrency related methods rg -A 5 "release.*[Cc]oncurrency" --type tsLikely an incorrect or invalid review comment.
49-103: Test logic seems inconsistent with PR objectives.The test is verifying that
releaseAllConcurrencyproperly decrements concurrency counters, but according to the PR objectives, the release concurrency feature has been entirely removed. If the feature is gone, these tests should either be deleted or updated to test the new simplified concurrency behavior.apps/webapp/app/components/runs/v3/RunFilters.tsx (1)
13-17: LGTM! Icon import updates for new status system.The import changes update the iconography to support the new run status system, replacing
ListCheckswithListFilterIconfrom lucide-react and addingListCheckedIconfrom local assets. The changes are consistent and focused.internal-packages/database/prisma/migrations/20250716145327_drop_release_concurrency_on_waitpoint_on_task_queue/migration.sql (1)
7-8: LGTM! Clean migration removing deprecated concurrency column.The migration correctly removes the
releaseConcurrencyOnWaitpointcolumn from theTaskQueuetable, aligning with the PR objectives to eliminate the release concurrency feature. The SQL syntax is proper for PostgreSQL.internal-packages/run-engine/src/run-queue/tests/enqueueMessage.test.ts (2)
10-10: LGTM! Proper import for burst factor support.The Decimal import enables the test to use precise arithmetic for the new concurrency burst factor feature.
32-32: LGTM! Burst factor property added correctly.The
concurrencyLimitBurstFactorproperty is properly initialized withnew Decimal(2.0), matching the default 2.0x burst factor mentioned in the PR objectives. This ensures the test environment reflects the new concurrency management system.apps/webapp/app/models/taskRun.server.ts (1)
132-132: LGTM! Proper placement of DEQUEUED status.The addition of
TaskRunStatus.DEQUEUEDto the pending status group is logically correct. A dequeued run that hasn't started executing yet should map toBatchTaskRunItemStatus.PENDING.internal-packages/database/prisma/migrations/20250715124534_add_concurrency_limit_burst_factor_to_runtime_environment/migration.sql (1)
1-2: LGTM! Well-designed migration for burst factor feature.The migration correctly adds the
concurrencyLimitBurstFactorcolumn with:
- Appropriate
DECIMAL(4,2)precision for burst factors up to 99.99- Safe default value of 2.00 matching the PR's 2.0x specification
- NOT NULL constraint with constant default (no table rewrite required)
internal-packages/database/prisma/migrations/20250716150513_add_dequeued_task_run_status/migration.sql (1)
1-2: LGTM! Clean enum extension for new status.The migration correctly adds the
'DEQUEUED'value to the existingTaskRunStatusenum using proper PostgreSQL syntax. This safely extends the enum without affecting existing data.apps/webapp/app/routes/api.v1.runs.$runParam.reschedule.ts (2)
5-5: LGTM! Proper import for API versioning.Clean import of the centralized API version utilities.
74-76: LGTM! Consistent API versioning integration.The API version extraction and passing to the presenter follows the established pattern across the codebase. This enables version-aware status mapping and response formatting.
packages/core/src/v3/schemas/runEngine.ts (1)
26-26: LGTM! Consistent schema addition for DEQUEUED status.The addition of
DEQUEUED: "DEQUEUED"is well-positioned in the task run lifecycle and maintains type safety with thesatisfiesconstraint. This completes the system-wide integration of the new status.apps/webapp/app/database-types.ts (1)
33-33: LGTM! Clean addition of the new DEQUEUED status.The addition follows the existing pattern and maintains consistency with the database schema through the
satisfiestype constraint.packages/core/src/v3/serverOnly/index.ts (1)
8-8: LGTM! Clean re-export of version constants.This appropriately exposes the API version constants to consumers of the serverOnly package, supporting the new API versioning system.
packages/core/src/v3/apiClient/stream.ts (2)
13-13: LGTM! Proper import of API version constants.Clean import that supports the new API versioning system.
47-47: LGTM! Correct addition of API version header.The header is properly added using the imported constant, maintaining consistency with the versioning system while preserving existing headers.
apps/webapp/app/routes/realtime.v1.runs.ts (2)
27-27: LGTM! Proper addition of apiVersion parameter.The parameter is correctly added to support API version-aware realtime streaming.
32-32: LGTM! Correct forwarding of apiVersion to streamRuns.The apiVersion parameter is properly passed through to the realtimeClient.streamRuns method, enabling version-aware streaming behavior.
apps/webapp/app/routes/api.v1.runs.ts (2)
20-20: LGTM! Proper addition of apiVersion parameter.The parameter is correctly added to enable API version-aware processing in the run list endpoint.
25-25: LGTM! Correct forwarding of apiVersion to presenter.The apiVersion parameter is properly passed to the presenter, enabling version-aware run list processing and status handling.
internal-packages/run-engine/src/run-queue/tests/nack.test.ts (2)
9-9: LGTM: Correct import for Decimal type.The import aligns with the database package export structure and supports the new burst factor functionality.
30-30: LGTM: Burst factor property correctly added.The
concurrencyLimitBurstFactorproperty with a default value of 2.0 matches the PR's documented default burst factor, enabling environment concurrency limits to exceed individual queue limits by 2x.apps/webapp/app/routes/realtime.v1.runs.$runId.ts (1)
42-42: LGTM: API versioning correctly implemented for realtime streaming.The addition of the
apiVersionparameter and its propagation torealtimeClient.streamRunenables version-aware streaming, supporting the new status mappings (likeDEQUEUED→EXECUTINGfor older API versions).Also applies to: 47-47
internal-packages/run-engine/src/run-queue/tests/ack.test.ts (2)
10-10: LGTM: Consistent import pattern across test files.The
Decimalimport follows the same pattern as other updated test files in the run-queue package.
32-32: LGTM: Consistent burst factor implementation.The burst factor property with
new Decimal(2.0)maintains consistency across test environments and supports the new concurrency management system.internal-packages/run-engine/src/run-queue/tests/concurrencySweeper.test.ts (1)
10-10: LGTM: Burst factor correctly added to concurrency sweeper test environment.The addition of
concurrencyLimitBurstFactoris particularly relevant for concurrency sweeper tests, ensuring the test environment reflects the new concurrency management capabilities introduced in this PR.Also applies to: 32-32
internal-packages/run-engine/src/shared/index.ts (1)
12-12: LGTM: Type definition correctly extended for burst factor support.The addition of
concurrencyLimitBurstFactortoMinimalAuthenticatedEnvironmentmaintains type safety by referencing the property fromAuthenticatedEnvironmentand enables burst factor functionality throughout the run engine components.apps/webapp/app/env.server.ts (1)
203-203: Verify the default burst factor value.The PR summary states that the Burst Factor should default to 2.0x, but the code sets the default to 1.0. This discrepancy could affect the intended behavior of the new concurrency burst feature.
Please clarify which default value is correct - the 2.0 mentioned in the PR summary or the 1.0 in the code.
packages/core/src/v3/apiClient/version.ts (1)
1-2: LGTM!Clean implementation of API versioning constants. The naming is clear and follows standard conventions for HTTP headers and date-based API versioning.
apps/webapp/app/v3/services/alerts/deliverAlert.server.ts (3)
15-15: LGTM!Correct import of the
RunStatustype from the core API schemas to support the new API versioning system.
44-44: LGTM!Correct import of the
CURRENT_API_VERSIONconstant from the new API versioning module.
357-360: LGTM!Correct integration with the API versioning system. The
ApiRetrieveRunPresenter.apiStatusFromRunStatusmethod now receives theCURRENT_API_VERSIONparameter to enable version-aware status mapping, and the result is properly cast to theRunStatustype.apps/webapp/app/routes/realtime.v1.batches.$batchId.ts (2)
29-29: LGTM!Correct addition of the
apiVersionparameter to the loader function signature to support API versioning in realtime streaming.
34-34: LGTM!Correct propagation of the
apiVersionparameter to therealtimeClient.streamBatchmethod, enabling version-aware streaming behavior.apps/webapp/app/v3/taskRunHeartbeatFailed.server.ts (1)
53-53: LGTM!Correct addition of the "DEQUEUED" status to the heartbeat failure handling. The treatment is consistent with other non-executing states, appropriately attempting to requeue the run when a heartbeat timeout occurs.
apps/webapp/app/routes/api.v1.projects.$projectRef.runs.ts (2)
20-20: LGTM! API versioning parameter added correctly.The loader function signature properly includes the
apiVersionparameter, which aligns with the broader API versioning support being introduced across the application.
28-28: LGTM! API version correctly passed to presenter.The
apiVersionparameter is properly passed to theApiRunListPresenter.callmethod, ensuring version-aware processing of run statuses and boolean helpers.apps/webapp/app/routes/api.v3.runs.$runId.ts (2)
30-30: LGTM! API versioning parameter added correctly.The loader function signature properly includes the
apiVersionparameter, consistent with the API versioning support being added across route handlers.
31-31: LGTM! API version correctly passed to presenter constructor.The
ApiRetrieveRunPresenteris properly instantiated with theapiVersionparameter, which aligns with the constructor changes shown in the relevant code snippet fromapps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts.apps/webapp/app/routes/resources.taskruns.$runParam.debug.ts (2)
34-34: LGTM! Burst factor field added for new concurrency feature.The addition of
concurrencyLimitBurstFactorto the runtime environment selection correctly supports the new concurrency burst factor feature introduced in this PR.
105-109: LGTM! Method name corrected for consistency.The change from
currentConcurrencyKeytoqueueCurrentConcurrencyKeyaligns with the method naming in the key producer classes, as confirmed by the relevant code snippets from bothapps/webapp/app/v3/marqs/marqsKeyProducer.tsandinternal-packages/run-engine/src/run-queue/keyProducer.ts.internal-packages/run-engine/src/engine/systems/runAttemptSystem.ts (1)
2-2: Import path for tryCatch is correct.Verified that
tryCatchis exported frompackages/core/src/utils.tsand properly exposed under"./utils"in the package’sexportsmapping. No further changes needed.packages/core/src/v3/types/tasks.ts (1)
844-844: LGTM! Version option correctly removed from wait operations.The
TriggerAndWaitOptionstype properly omits the "version" option fromTriggerOptions, which enforces that wait operations are locked to the same version as the parent task. This aligns with the documented behavior mentioned in theTriggerOptions.versioncomment (lines 838-841) that wait versions should always use the parent task's version.apps/webapp/app/routes/engine.v1.runs.$runFriendlyId.waitpoints.tokens.$waitpointFriendlyId.wait.ts (1)
19-42: LGTM! Consistent removal of release concurrency feature.The removal of the
releaseConcurrencyparameter from both the request body schema and theengine.blockRunWithWaitpointcall is consistent with the PR objectives to eliminate the release concurrency subsystem. The default behavior is now that concurrency is never released when a run is initially blocked at a waitpoint.apps/webapp/app/v3/runEngine.server.ts (1)
43-43: LGTM! Proper addition of concurrency burst factor configuration.The addition of
defaultEnvConcurrencyBurstFactorfrom the environment variable follows the established pattern for configuration options and supports the new burst factor feature that replaces the removed release concurrency system. This allows environment-wide concurrency limits to be temporarily exceeded by a configurable multiplier.internal-packages/run-engine/src/run-queue/index.test.ts (2)
11-11: LGTM! Proper import for Decimal type.The import of
Decimalfrom@trigger.dev/databaseis correct and necessary for the newconcurrencyLimitBurstFactorproperty in test environment objects.
34-34: LGTM! Appropriate test data for burst factor feature.The addition of
concurrencyLimitBurstFactor: new Decimal(1.0)to both test environment objects correctly supports the new burst factor feature. Using1.0as the default value is appropriate for tests as it represents no burst multiplier (1x the base concurrency limit).Also applies to: 43-43
packages/core/src/v3/apiClient/index.ts (3)
80-80: LGTM! Proper import of API versioning constants.The import of
API_VERSIONandAPI_VERSION_HEADER_NAMEfrom the version module enables proper API versioning support for client requests.
777-796: LGTM! Consistent removal of release concurrency parameter.The
waitForWaitpointTokenmethod correctly removes thereleaseConcurrencyparameter from both the method signature and request body, aligning with the broader removal of the release concurrency feature. The method now makes a simple POST request without any body, which is appropriate for the simplified waitpoint token waiting behavior.
1039-1040: LGTM! Proper API versioning implementation.Adding the API version header to all requests using the imported constants enables version-aware server-side handling of requests. This supports the new status semantics and concurrency behavior changes mentioned in the PR objectives.
apps/webapp/app/services/routeBuilders/apiBuilder.server.ts (4)
24-24: LGTM: API versioning support added systematically.The addition of API version imports aligns with the broader API versioning initiative described in the PR objectives.
91-91: LGTM: Handler signatures updated for API versioning.The handler function types have been properly extended to include the
apiVersionparameter, maintaining type safety.Also applies to: 315-315
242-252: LGTM: API version extraction and propagation implemented correctly.The API version is properly extracted from the request using
getApiVersion(request)and passed to the respective handler functions in both loader routes.Also applies to: 399-408
465-487: Versioning is handled by the route file path, not the builder options
BothcreateLoaderApiRouteandcreateActionApiRouteomit an explicitapiVersionparameter because versioning is inferred from the file names (e.g.api.v1.*). You don’t need to add version support to the handler types or route-builder options—this is intentional.Likely an incorrect or invalid review comment.
apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.queues/route.tsx (1)
427-428: LGTM: Improved visual emphasis for running task counts.The styling changes enhance readability by making running task counts more prominent with
text-text-brightwhenqueue.running > 0, while maintaining the warning styling when at concurrency limits. This improves the user experience for monitoring queue activity.Also applies to: 432-433
internal-packages/run-engine/src/engine/types.ts (2)
41-41: LGTM: Burst factor configuration added.The addition of
defaultEnvConcurrencyBurstFactorproperty supports the new Burst Factor feature mentioned in the PR objectives, which allows environment-wide concurrency limits to exceed individual queue limits by a configurable multiplier (defaulting to 2.0x).
79-132: LGTM: Release concurrency configuration successfully removed.The removal of
releaseConcurrencyandrunChainStateproperties fromTriggerParams, along with the entire release concurrency configuration block fromRunEngineOptions, aligns perfectly with the PR objectives to simplify the concurrency management system. This comprehensive cleanup eliminates the complex release concurrency feature in favor of the new default behavior where concurrency is never released at waitpoints but always released during checkpoints and shutdowns.internal-packages/database/prisma/schema.prisma (2)
250-252: LGTM: Concurrency burst factor implementation looks solid.The new
concurrencyLimitBurstFactorfield is properly typed asDecimal(4,2)with a sensible default of 2.0x. This aligns perfectly with the PR objectives to allow environment concurrency limits to exceed queue limits by this factor.
774-776: LGTM: New DEQUEUED status positioned correctly.The
DEQUEUEDstatus is appropriately placed betweenWAITING_FOR_DEPLOYandEXECUTINGin the task run lifecycle, which makes logical sense for tracking runs that have been pulled from the queue but haven't started executing yet.internal-packages/run-engine/src/run-queue/tests/fairQueueSelectionStrategy.test.ts (3)
79-125: LGTM: Comprehensive test for burst factor functionality.The new test case properly validates that the
FairQueueSelectionStrategyrespects environment concurrency limits when a burst factor is applied. The test setup correctly simulates a scenario where current concurrency (3) exceeds the base limit (2) but remains within the burst factor allowance (2 × 2 = 4), expecting the queue to still be selected.
1253-1253: LGTM: Type extension supports new test functionality.The addition of the optional
limitBurstFactorproperty toSetupConcurrencyOptionsproperly supports the new burst factor testing capabilities.
1267-1272: LGTM: Helper function correctly implements burst factor setup.The
setupConcurrencyfunction properly sets the Redis key for the concurrency limit burst factor when provided, enabling the test scenarios to validate burst factor behavior.packages/trigger-sdk/src/v3/wait.ts (1)
596-602: LGTM! Concurrency release option successfully removed.The
wait.forTokenfunction parameter has been correctly simplified to only accept the token parameter, aligning with the PR's objective to removereleaseConcurrencyoptions. This is consistent with the broader removal of concurrency release mechanisms across the codebase.internal-packages/run-engine/src/engine/systems/dequeueSystem.ts (1)
318-318: Explicit DEQUEUED status assignment enhances status clarity.Good addition of explicit
status: "DEQUEUED"assignment when locking a task run for execution. This aligns with the new run status system introduced in the PR, providing clear state transitions and better visibility into run lifecycle stages.packages/core/src/v3/resource-catalog/standardResourceCatalog.ts (1)
29-44: Queue metadata validation simplified correctly.The removal of
releaseConcurrencyOnWaitpointhandling from queue metadata registration is well-executed. The logic now only validatesconcurrencyLimitdifferences, which aligns with the PR's objective of removing concurrency release features while maintaining proper queue validation.internal-packages/run-engine/src/engine/systems/checkpointSystem.ts (2)
195-202: Concurrency management simplified and centralized.Excellent refactoring that replaces the dedicated
ReleaseConcurrencySystemwith the centralizedthis.$.runQueue.releaseAllConcurrencymethod. The addition of debug logging and the conditional check forrun.organizationIdimproves observability and robustness.
233-240: Consistent concurrency release logic maintained.The same simplified concurrency release pattern is correctly applied here, maintaining consistency with the checkpoint-and-queue path above. The debug logging will be valuable for troubleshooting concurrency-related issues.
internal-packages/run-engine/src/engine/tests/setup.ts (3)
9-9: Decimal import added for burst factor support.Good addition of the
Decimalimport to support the newconcurrencyLimitBurstFactorfield in the runtime environment setup.
68-68: Burst factor properly initialized with default value.Excellent addition of
concurrencyLimitBurstFactor: new Decimal(2.0)which aligns with the PR's introduction of the Burst Factor feature with a default value of 2.0x. This allows environment-wide concurrency limits to temporarily exceed individual queue limits.
95-95: Environment concurrency limits properly initialized.Good addition of the
updateEnvConcurrencyLimitscall to ensure the environment's concurrency limits are properly set up in the run queue, supporting the new concurrency management model.internal-packages/run-engine/src/run-queue/tests/keyProducer.test.ts (8)
31-40: LGTM!The test correctly validates the burst factor key generation and follows the established pattern.
42-51: LGTM!The test correctly validates the environment-level dequeued count key generation.
82-96: Good naming improvement!The rename to
queueConcurrencyLimitKeyFromQueueimproves consistency with other queue-related methods.
98-111: Good test coverage!Testing both with and without concurrency key ensures the method correctly extracts the limit key regardless of the presence of a concurrency key.
113-176: Consistent naming improvements!The renamed methods with
queueprefix improve API consistency, and the test coverage for both concurrency key scenarios is comprehensive.
178-241: Excellent test coverage for the new dequeued tracking feature!The tests properly validate key generation for tracking dequeued counts at the queue level, with comprehensive coverage for both concurrency key scenarios.
258-271: LGTM!The test correctly validates extracting the environment burst factor key from a queue key.
288-301: LGTM!The test properly validates extracting the environment dequeued count key from a queue key.
internal-packages/run-engine/src/run-queue/fairQueueSelectionStrategy.ts (2)
502-515: Well-implemented burst factor integration!The parallel fetching of values is efficient, and the burst factor calculation correctly floors the result to ensure integer concurrency limits. The enhanced tracing will help with debugging.
591-611: LGTM!The burst factor retrieval is correctly implemented with a sensible default of 1.0 (no burst effect). The method follows the established pattern for Redis value retrieval.
packages/core/src/v3/schemas/api.ts (2)
640-667: LGTM!The RunStatus enum updates correctly implement the new status model with clear documentation for each status.
716-716: LGTM!The
isWaitingboolean helper is correctly added to match the newWAITINGstatus.internal-packages/run-engine/src/engine/systems/waitpointSystem.ts (2)
348-477: Clean removal of concurrency release logic!The
blockRunWithWaitpointmethod has been properly simplified by removing all concurrency release logic, making the code cleaner and more focused on its core responsibility.
597-639: Excellent simplification of the continue logic!The removal of concurrency reacquisition logic makes this method much cleaner. The direct transition to EXECUTING status with immediate worker notification is more straightforward.
apps/webapp/test/realtimeClient.test.ts (4)
5-5: LGTM!The import correctly brings in the API version constants needed for the test updates.
72-79: Consistent API version parameter additions.All
streamRunandstreamRunscalls have been properly updated to include theNON_SPECIFIC_API_VERSIONparameter, ensuring backward compatibility testing.Also applies to: 83-90, 112-119, 123-130, 223-232, 309-314, 318-325, 347-352, 356-361
389-467: Well-structured test for backward compatibility.This test correctly verifies that the
DEQUEUEDstatus is rewritten toEXECUTINGfor older API versions, ensuring backward compatibility with clients that don't recognize the new status.
469-547: Comprehensive test coverage for the new DEQUEUED status.This test complements the previous one by verifying that the
DEQUEUEDstatus is preserved for clients using the current API version, ensuring the new status is properly exposed to updated clients.internal-packages/run-engine/src/run-queue/tests/dequeueMessageFromWorkerQueue.test.ts (5)
9-9: LGTM!Appropriate import of
Decimaltype for handling the concurrency burst factor with proper precision.
30-30: Correct implementation of the burst factor feature.The addition of
concurrencyLimitBurstFactorwith a value of 2.0 aligns with the PR's burst factor feature, allowing environments to temporarily exceed their base concurrency limit.
201-283: Comprehensive test for burst factor enforcement.This test effectively validates the burst factor behavior:
- Allows dequeuing up to the burst limit (2x base limit)
- Prevents dequeuing beyond the burst limit
- Works correctly across different queues
285-349: Clear validation of burst factor allowing increased concurrency.This test provides a straightforward verification that the burst factor correctly allows exceeding the base concurrency limit.
351-411: Important test for queue-level concurrency constraints.This test correctly validates that burst factor applies only to environment-wide concurrency limits, not individual queue limits. This ensures proper isolation between queues.
apps/webapp/app/api/versions.ts (4)
1-11: Well-structured API version management.The imports correctly use the subpath export from
@trigger.dev/core, and the constants provide a clean abstraction for API versioning.
13-21: Clean API version extraction logic.The function correctly handles API version detection with a sensible fallback for backward compatibility.
23-55: Consider the maintenance implications of duplicating the enum.While the duplication allows for version-specific handling, it creates a maintenance burden. Any changes to the core enum will need to be manually synchronized here.
Consider creating a shared type that can be imported instead of duplicating, or document the synchronization process.
57-57: LGTM!Standard pattern for exporting zod-inferred types.
apps/webapp/app/presenters/v3/ApiRunListPresenter.server.ts (6)
1-5: LGTM!Imports correctly updated to support API versioning with proper subpath usage for the core package.
27-29: Excellent backward compatibility handling.The use of
RunStatus.or(RunStatusUnspecifiedApiVersion)allows the API to accept both current and legacy status values, ensuring smooth transitions for clients.
112-117: API version parameter properly integrated.The addition of the
apiVersionparameter enables version-aware response formatting.
147-147: Good use of read replicas for scalability.Using
this._replicafor read operations helps distribute database load and improves performance.Also applies to: 215-215
223-265: Consistent API version propagation.The
apiVersionparameter is correctly passed through to all status mapping calls, ensuring version-aware responses throughout.
277-335: Comprehensive status mapping updates.The method correctly handles the new
DEQUEUEDandWAITINGstatuses, maintaining consistency with the updated status system.apps/webapp/app/components/runs/v3/TaskRunStatus.tsx (5)
22-56: Correct categorization of the DEQUEUED status.The
DEQUEUEDstatus is appropriately included in the status arrays and correctly categorized as a running status since it represents an active state in the task lifecycle.Also applies to: 85-90
63-63: Clear and accurate status description.The description effectively communicates the transitional nature of the
DEQUEUEDstatus.
169-170: Consistent icon usage.Using
RectangleStackIconforDEQUEUEDmaintains visual consistency with other queue-related statuses.
212-213: Appropriate color classification.The
text-pendingcolor correctly groupsDEQUEUEDwith other active execution states.
248-249: LGTM!Clear and consistent status title.
internal-packages/run-engine/src/engine/index.ts (1)
128-128: LGTM! Burst factor parameter added correctly.The addition of
defaultEnvConcurrencyBurstFactorto the run queue configuration aligns with the PR's new "Burst Factor" feature for environment concurrency limits.internal-packages/run-engine/src/run-queue/types.ts (2)
49-52: Good separation of concerns with the new type alias.The
RunQueueKeyProducerEnvironmenttype appropriately omits concurrency-related properties that aren't needed for key generation, following the principle of least privilege.
82-87: New dequeued tracking methods support the DEQUEUED status.The addition of
queueCurrentDequeuedKeyandenvCurrentDequeuedKeymethods properly supports tracking of the new DEQUEUED status for accurate concurrency management.Also applies to: 96-105
apps/webapp/app/presenters/v3/ApiRetrieveRunPresenter.server.ts (2)
254-257: Excellent backward compatibility handling for DEQUEUED status.The V1 implementation correctly maps DEQUEUED to EXECUTING for older API versions, while V2 preserves the distinct DEQUEUED status. This ensures clients using older API versions continue to work correctly.
Also applies to: 306-308
368-368: Good addition of isWaiting boolean helper.The new
isWaitingboolean helper properly corresponds to the new WAITING status, providing a convenient way for API consumers to check this state.Also applies to: 377-377
packages/core/src/v3/apiClient/runStream.ts (2)
48-54: Excellent addition of boolean helper properties.The boolean helpers (
isQueued,isExecuting,isWaiting, etc.) significantly improve API usability by providing intuitive state checks without requiring consumers to understand the full status model.
451-468: Well-structured status categorization.The use of arrays to categorize statuses makes the boolean helper logic clear and maintainable. The
booleanHelpersFromRunStatusfunction correctly implements the status-to-boolean mappings.internal-packages/run-engine/src/run-queue/index.ts (2)
2123-2153: Verify Redis key construction in Lua scriptThe
dequeueMessageFromKeyLua script constructs Redis keys by string manipulation on line 2144. This approach could be fragile if the queue key format changes.Consider using a more robust key construction method or passing the dequeued keys as parameters to ensure consistency with the key producer logic.
2534-2547: Good forward compatibility approachThe
parseRawMessagefunction's approach of returning the deserialized message even when validation fails is a smart way to handle schema evolution. This prevents breaking changes while still logging validation errors for monitoring.
| @@ -200,6 +200,7 @@ const EnvironmentSchema = z.object({ | |||
| PUBSUB_REDIS_CLUSTER_MODE_ENABLED: z.string().default("0"), | |||
|
|
|||
| DEFAULT_ENV_EXECUTION_CONCURRENCY_LIMIT: z.coerce.number().int().default(100), | |||
| DEFAULT_ENV_EXECUTION_CONCURRENCY_BURST_FACTOR: z.coerce.number().default(1.0), | |||
There was a problem hiding this comment.
@nicktrn we'll need to document this for the self-hosting guides/charts. We can recommend setting this to 2.0
|
Question about this change. If a parent task triggers and waits for a subtask, with both tasks being on different queues, does that mean this now fills up 2 concurrency slots? Or does it behave like in v3, where the parent task's concurrency is released to the environment, allowing the subtask to take up the slot (https://trigger.dev/docs/queue-concurrency#waiting-for-a-subtask-on-a-different-queue) I'm asking because we had an issue migrating to v4, with deadlock as a result of parent tasks triggering subtasks, which ended up being queued because the parent task's slot wasn't released (in this case we trigged many at the same time, this filling up our environment's concurrency limit). We just fixed that, but setting |
Removes the
releaseConcurrencyOnWaitpointoption on queues and thereleaseConcurrencyoption on various wait functions. Replaced with the following default behavior:Additionally, environment concurrency limits now have a new "Burst Factor", defaulting to 2.0x. The "Burst Factor" allows the environment-wide concurrency limit to be higher than any individual queue's concurrency limit. For example, if you have an environment concurrency limit of 100, and a Burst Factor of 2.0x, then you can execute up to 200 runs concurrently, but any one task/queue can still only execute 100 runs concurrently.
We've done some work cleaning up the run statuses. The new statuses are:
PENDING_VERSION: Task is waiting for a version update because it cannot execute without additional information (task, queue, etc.)QUEUED: Task is waiting to be executed by a workerDEQUEUED: Task has been dequeued and is being sent to a worker to start executing.EXECUTING: Task is currently being executed by a workerWAITING: Task has been paused by the system, and will be resumed by the systemCOMPLETED: Task has been completed successfullyCANCELED: Task has been canceled by the userFAILED: Task has failed to complete, due to an error in the taskCRASHED: Task has crashed and won't be retried, most likely the worker ran out of resources, e.g. memory or storageSYSTEM_FAILURE: Task has failed to complete, due to an error in the systemDELAYED: Task has been scheduled to run at a specific timeEXPIRED: Task has expired and won't be executedTIMED_OUT: Task has reached it's maxDuration and has been stoppedWe've removed the following statuses:
WAITING_FOR_DEPLOY: This is no longer used, and is replaced byPENDING_VERSIONFROZEN: This is no longer used, and is replaced byWAITINGINTERRUPTED: This is no longer usedREATTEMPTING: This is no longer used, and is replaced byEXECUTINGWe've also added "boolean" helpers to runs returned via the API and from Realtime:
isQueued: Returns true when the status isQUEUED,PENDING_VERSION, orDELAYEDisExecuting: Returns true when the status isEXECUTING,DEQUEUED. These count against your concurrency limits.isWaiting: Returns true when the status isWAITING. These do not count against your concurrency limits.isCompleted: Returns true when the status is any of the completed statuses.isCanceled: Returns true when the status isCANCELEDisFailed: Returns true when the status is any of the failed statuses.isSuccess: Returns true when the status isCOMPLETEDThis change adds the ability to easily detect which runs are being counted against your concurrency limit by filtering for both
EXECUTINGorDEQUEUED.