Conversation
Deprecate maxDuration in favour of maxComputeSeconds but keep backwards compatibility
🦋 Changeset detectedLatest commit: 4cf8b69 The changes in this PR will be included in the next version bump. This PR includes changesets to release 28 packages
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 |
WalkthroughThe PR renames the public configuration option Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
docs/runs/max-duration.mdx (1)
9-11:⚠️ Potential issue | 🟡 MinorDeprecation note is reversed.
Line 10 currently says
maxDurationreplaces deprecatedmaxComputeSeconds, but this page and PR migrate in the opposite direction. It should statemaxComputeSecondsreplaces deprecatedmaxDuration.Proposed fix
<Note> - `maxDuration` replaces the deprecated `maxComputeSeconds` parameter. Both work the same way, but we recommend using `maxDuration` for clarity. + `maxComputeSeconds` replaces the deprecated `maxDuration` parameter. Both work the same way, but we recommend using `maxComputeSeconds` for clarity. </Note>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/runs/max-duration.mdx` around lines 9 - 11, The Note's deprecation wording is reversed: change the sentence to say that `maxComputeSeconds` replaces the deprecated `maxDuration` (instead of the current opposite claim). Update the Note block text to read something like "`maxComputeSeconds` replaces the deprecated `maxDuration`; both work the same way, but we recommend using `maxComputeSeconds` for clarity," and check adjacent references to `maxDuration`/`maxComputeSeconds` in the same file to ensure consistency.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/runs/max-duration.mdx`:
- Line 15: Replace the short `ts` code-fence tags with the required `typescript`
tag in the docs examples: update the fences referencing
`/config/trigger.config.ts`, `/trigger/max-duration.ts`, and
`/trigger/max-duration-task.ts` (and the repeated instances noted at lines 44,
66, 82, 98, 112, 129) so each opening fence reads ```typescript <path> instead
of ```ts <path>; ensure all matching closing fences remain unchanged.
- Line 99: The import path for the example snippet is incorrect: update the
import of maxComputeSecondsTask from "./trigger/max-duration-task" to the
sibling module "./max-duration-task" so the snippet is runnable; locate the
import statement that references maxComputeSecondsTask and replace the nested
"./trigger/max-duration-task" module path with "./max-duration-task" (also
update the duplicate occurrence noted further down).
---
Duplicate comments:
In `@docs/runs/max-duration.mdx`:
- Around line 9-11: The Note's deprecation wording is reversed: change the
sentence to say that `maxComputeSeconds` replaces the deprecated `maxDuration`
(instead of the current opposite claim). Update the Note block text to read
something like "`maxComputeSeconds` replaces the deprecated `maxDuration`; both
work the same way, but we recommend using `maxComputeSeconds` for clarity," and
check adjacent references to `maxDuration`/`maxComputeSeconds` in the same file
to ensure consistency.
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/runs/max-duration.mdx
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (26)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: sdk-compat / Bun Runtime
🧰 Additional context used
📓 Path-based instructions (2)
docs/**/*.{md,mdx}
📄 CodeRabbit inference engine (CLAUDE.md)
Docs in docs/ directory should use Mintlify MDX format following conventions in docs/CLAUDE.md
Files:
docs/runs/max-duration.mdx
docs/**/*.mdx
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.mdx: MDX documentation pages must include frontmatter with title (required), description (required), and sidebarTitle (optional) in YAML format
Use Mintlify components for structured content: , , , , , , /, /
Always import from@trigger.dev/sdkin code examples (never from@trigger.dev/sdk/v3)
Code examples must be complete and runnable where possible
Use language tags in code fences:typescript,bash,json
Files:
docs/runs/max-duration.mdx
🧠 Learnings (16)
📓 Common learnings
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger.config.ts : Set default maximum duration in trigger.config.ts using `maxDuration` property
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task duration using the `maxDuration` property (in seconds)
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger.config.ts : Set default maximum duration in trigger.config.ts using `maxDuration` property
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Limit task duration using the `maxDuration` property (in seconds)
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Configure task retry behavior using the `retry` property with options like maxAttempts, factor, and timeout values
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `idempotencyKeyTTL` option to define a time window during which duplicate triggers return the original run
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use the `task()` function from `trigger.dev/sdk/v3` to define tasks with id and run properties
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.trigger()` to trigger a task from inside another task with specified payload
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `tasks.batchTrigger()` to trigger multiple runs of a single task with different payloads
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerByTaskAndWait()` to batch trigger tasks by passing task instances and wait for results
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `schedules.task()` for scheduled/cron tasks instead of regular `task()`
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `yourTask.batchTrigger()` to trigger multiple runs of a task from inside another task
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use `batch.triggerByTask()` to batch trigger tasks by passing task instances for static task sets
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger.config.ts : Configure global retry settings in trigger.config.ts using `retries` object with defaults for all tasks
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger.config.ts : Configure Trigger.dev project in `trigger.config.ts` using `defineConfig()` with project ref and task directories
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Attach metadata to task runs using the metadata option when triggering, and access/update it inside runs using metadata functions
Applied to files:
docs/runs/max-duration.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Applies to **/trigger.config.ts : Define global lifecycle functions (onStart, onSuccess, onFailure) in trigger.config.ts to apply to all tasks
Applied to files:
docs/runs/max-duration.mdx
|
|
||
| You must set a default maxComputeSeconds in your `trigger.config.ts` file, which will apply to all tasks unless overridden: | ||
|
|
||
| ```ts /config/trigger.config.ts |
There was a problem hiding this comment.
Use typescript code-fence tags in docs examples.
These fences use ts; the docs guideline requires typescript.
Proposed fix
-```ts /config/trigger.config.ts
+```typescript /config/trigger.config.ts
@@
-```ts /trigger/max-duration.ts
+```typescript /trigger/max-duration.ts
@@
-```ts /trigger/max-duration-task.ts
+```typescript /trigger/max-duration-task.ts
@@
-```ts /trigger/max-duration-task.ts
+```typescript /trigger/max-duration-task.ts
@@
-```ts /trigger/max-duration.ts
+```typescript /trigger/max-duration.ts
@@
-```ts /trigger/max-duration.ts
+```typescript /trigger/max-duration.ts
@@
-```ts /trigger/max-duration-task.ts
+```typescript /trigger/max-duration-task.tsAs per coding guidelines, Use language tags in code fences: typescript, bash, json.
Also applies to: 44-44, 66-66, 82-82, 98-98, 112-112, 129-129
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/runs/max-duration.mdx` at line 15, Replace the short `ts` code-fence
tags with the required `typescript` tag in the docs examples: update the fences
referencing `/config/trigger.config.ts`, `/trigger/max-duration.ts`, and
`/trigger/max-duration-task.ts` (and the repeated instances noted at lines 44,
66, 82, 98, 112, 129) so each opening fence reads ```typescript <path> instead
of ```ts <path>; ensure all matching closing fences remain unchanged.
|
|
||
| ```ts /trigger/max-duration.ts | ||
| import { maxDurationTask } from "./trigger/max-duration-task"; | ||
| import { maxComputeSecondsTask } from "./trigger/max-duration-task"; |
There was a problem hiding this comment.
Snippet import path is not runnable from the shown file location.
In /trigger/max-duration.ts, importing ./trigger/max-duration-task points to a nested directory. The sibling-file import should be ./max-duration-task.
Proposed fix
-import { maxComputeSecondsTask } from "./trigger/max-duration-task";
+import { maxComputeSecondsTask } from "./max-duration-task";
@@
-import { maxComputeSecondsTask } from "./trigger/max-duration-task";
+import { maxComputeSecondsTask } from "./max-duration-task";As per coding guidelines, Code examples must be complete and runnable where possible.
Also applies to: 113-113
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/runs/max-duration.mdx` at line 99, The import path for the example
snippet is incorrect: update the import of maxComputeSecondsTask from
"./trigger/max-duration-task" to the sibling module "./max-duration-task" so the
snippet is runnable; locate the import statement that references
maxComputeSecondsTask and replace the nested "./trigger/max-duration-task"
module path with "./max-duration-task" (also update the duplicate occurrence
noted further down).
There was a problem hiding this comment.
🔴 createSchemaTask ignores maxComputeSeconds, only reads deprecated maxDuration
When defining a task using createSchemaTask (used by schemaTask() and toolTask()), the new maxComputeSeconds property is silently ignored because the metadata registration still only reads params.maxDuration.
Root Cause and Impact
In createTask at packages/trigger-sdk/src/v3/shared.ts:238, the fix was correctly applied:
maxDuration: params.maxComputeSeconds ?? params.maxDuration,But in createSchemaTask at packages/trigger-sdk/src/v3/shared.ts:369, the transformation was missed:
maxDuration: params.maxDuration,This means any task defined via createSchemaTask (which powers schemaTask() and indirectly toolTask() via createToolTask at line 271) that uses the new maxComputeSeconds property will have no compute time limit applied. The maxComputeSeconds value is accepted by the type system but silently dropped.
Impact: Users who follow the new documentation and set maxComputeSeconds on schema-based tasks will have no duration limit enforced, potentially leading to runaway tasks and unexpected compute costs.
(Refers to line 369)
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
🔴 triggerAndWait_internal ignores maxComputeSeconds, only reads deprecated maxDuration
When calling triggerAndWait() or task.triggerAndWait() with the new maxComputeSeconds option, the value is silently ignored because triggerAndWait_internal only reads options?.maxDuration.
Root Cause and Impact
At packages/trigger-sdk/src/v3/shared.ts:2399, the code reads:
maxDuration: options?.maxDuration,Every other trigger path (e.g., trigger_internal at line 2142, all batch trigger functions, and all streaming transform functions) was correctly updated to:
maxDuration: options?.maxComputeSeconds ?? options?.maxDuration,The TriggerAndWaitOptions type (defined at packages/core/src/v3/types/tasks.ts:987 as Omit<TriggerOptions, "version">) inherits the maxComputeSeconds field from TriggerOptions, so users can pass it — but it will be silently dropped.
Impact: Users calling triggerAndWait() with maxComputeSeconds will have no duration override applied to the child run, potentially causing it to run with the task's default or no limit at all.
(Refers to line 2399)
Was this helpful? React with 👍 or 👎 to provide feedback.
|
|
||
| You must set a default maxDuration in your `trigger.config.ts` file, which will apply to all tasks unless overridden: | ||
| <Note> | ||
| `maxDuration` replaces the deprecated `maxComputeSeconds` parameter. Both work the same way, but we recommend using `maxDuration` for clarity. |
There was a problem hiding this comment.
🔴 Documentation note says the opposite of what's intended — claims maxDuration replaces maxComputeSeconds
The deprecation note in the documentation has the old and new names swapped, telling users the exact opposite of the PR's intent.
Details
At docs/runs/max-duration.mdx:10, the note reads:
`maxDuration` replaces the deprecated `maxComputeSeconds` parameter.
But the entire PR is about deprecating maxDuration in favor of maxComputeSeconds. The note should say:
`maxComputeSeconds` replaces the deprecated `maxDuration` parameter.
Impact: Users reading this documentation will be confused about which property to use — the note directly contradicts all other documentation and code changes in this PR.
| `maxDuration` replaces the deprecated `maxComputeSeconds` parameter. Both work the same way, but we recommend using `maxDuration` for clarity. | |
| `maxComputeSeconds` replaces the deprecated `maxDuration` parameter. Both work the same way, but we recommend using `maxComputeSeconds` for clarity. |
Was this helpful? React with 👍 or 👎 to provide feedback.
| maxComputeSeconds?: number; | ||
|
|
||
| /** | ||
| * @deprecated Use `maxComputeSeconds` instead. This property will be removed in a future version. | ||
| * | ||
| * The maximum duration in compute-time seconds that a task run is allowed to run. If the task run exceeds this duration, it will be stopped. | ||
| * | ||
| * Minimum value is 5 seconds | ||
| * | ||
| * Setting this value will affect all tasks in the project. | ||
| */ | ||
| maxDuration?: number; |
There was a problem hiding this comment.
🚩 Config maxDuration changed from required to optional — potential breaking change for existing configs
In packages/core/src/v3/config.ts:177, the TriggerConfig type previously had maxDuration: number (required). Now it's been changed to maxComputeSeconds?: number (optional) and maxDuration?: number (optional). This is technically a widening change that shouldn't break existing code at compile time, but it means the config no longer enforces that users set a compute time limit. The changeset docs and templates all include maxComputeSeconds, so new projects will still have it, but existing projects upgrading could silently lose their enforcement if they relied on the type system requiring the field.
Was this helpful? React with 👍 or 👎 to provide feedback.
| maxComputeSeconds: 300, // 300 seconds or 5 minutes | ||
| run: async (payload: any, { ctx }) => { | ||
| console.log(ctx.run.maxDuration); // 300 | ||
| console.log(ctx.run.maxComputeSeconds); // 300 |
There was a problem hiding this comment.
🚩 Documentation references ctx.run.maxComputeSeconds but the runtime context schema likely still uses maxDuration
At docs/runs/max-duration.mdx:136, the docs show ctx.run.maxComputeSeconds as the way to access the value in the run context. However, the runtime context schemas at packages/core/src/v3/schemas/messages.ts:195 use maxDurationInSeconds, and no changes were made to the context/schemas in this PR. This means ctx.run.maxComputeSeconds likely doesn't exist at runtime — it's probably still ctx.run.maxDuration or ctx.run.maxDurationInSeconds. This documentation claim should be verified against the actual runtime context type.
Was this helpful? React with 👍 or 👎 to provide feedback.
Deprecate maxDuration in favour of maxComputeSeconds while preserving backwards compatibility
Details
Todo