feat(sdk): replace `maxDuration` with `maxComputeSeconds` (user-facing rename) [TRI-9126] by matt-aitken · Pull Request #3533 · triggerdotdev/trigger.dev

matt-aitken · 2026-05-07T10:38:11Z

Summary

User-facing rename of maxDuration → maxComputeSeconds on defineConfig, task definitions, and trigger options. The legacy maxDuration field stays in place but is JSDoc-deprecated; if both are set, maxComputeSeconds wins. Internal SDK/CLI/run-engine code (~380 references to maxDurationInSeconds) is not touched — translation happens at the user-facing boundary only.

Linear: TRI-9126

Why

maxDuration is in seconds but users frequently pass milliseconds by mistake (e.g. maxDuration: 300000 thinking "5 minutes"). The new name makes the unit unambiguous at the call site.

What changed

@trigger.dev/core — added maxComputeSeconds?: number and JSDoc-deprecated maxDuration on TriggerConfig, CommonTaskOptions, and TriggerOptions.
@trigger.dev/sdk — defineConfig collapses maxComputeSeconds ?? maxDuration into the existing maxDuration slot. New resolveMaxComputeSeconds helper applied at all 16 user-input sites in shared.ts (task definitions, trigger, triggerAndWait, batchTrigger, batchTriggerAndWait).
trigger.dev CLI — six init templates updated (trigger.config.ts/.mjs, examples/simple.ts/.mjs, examples/schedule.ts/.mjs).
references/hello-world — trigger.config.ts and example.ts (maxDurationTask per-task value + maxDurationParentTask per-trigger override) updated for manual testing.
Tests — 9 new precedence tests for defineConfig and the resolver helper.
Changeset — patch on @trigger.dev/core, @trigger.dev/sdk, trigger.dev.

Out of scope

Internal maxDurationInSeconds field (DB, ClickHouse, run engine, MarQS, dashboard presenters) — unchanged.
The getMaxDuration() precedence helper in packages/core/src/v3/isomorphic/maxDuration.ts — unchanged.
Public docs at docs/ — separate dedicated pass.
rules/ and .claude/skills/trigger-dev-tasks/ — explicitly excluded by repo conventions.
Runtime warning when maxDuration is used — out of scope; deprecation is JSDoc-only for now.

Test plan

pnpm run build --filter @trigger.dev/core — clean
pnpm run build --filter @trigger.dev/sdk — clean
Core test suite — 442/442 pass
SDK test suite — 19/19 pass (incl. 9 new)
Manual: cd references/hello-world && pnpm exec trigger dev, trigger max-duration task, confirm 5s timeout still kicks in
Manual: trigger max-duration-parent and confirm { maxComputeSeconds: timeout.None } overrides the task's per-task limit
Manual: fresh trigger init in a temp dir, confirm generated trigger.config.ts and example task use maxComputeSeconds

🤖 Generated with Claude Code

…ng types

- defineConfig: resolves maxComputeSeconds ?? maxDuration into maxDuration - new resolveMaxComputeSeconds helper for shared.ts - task definitions, trigger and batchTrigger options funnel through helper Internal references to maxDuration (run engine, queues, DB) are unchanged.

…sting - trigger.config.ts: top-level maxComputeSeconds - example.ts: per-task maxComputeSeconds on maxDurationTask - example.ts: per-trigger override on triggerAndWait Variable name maxDurationTask kept since it labels the legacy fixture concept; the payload.maxDuration field is unrelated to the SDK property and untouched.

coderabbitai · 2026-05-07T10:42:23Z

Walkthrough

This PR introduces maxComputeSeconds as the primary user-facing API for configuring task compute-time limits across the Trigger.dev SDK, replacing the legacy maxDuration. The change spans type definitions, configuration handling, SDK implementations, and project templates. A new resolveMaxComputeSeconds helper ensures backward compatibility by accepting both options and applying precedence rules where maxComputeSeconds takes priority. The implementation normalizes both options into a single maxDuration value propagated internally through task creation, single-task triggers, batch triggers, and streaming transformations. All CLI v3 initialization templates and examples are updated to use the new naming convention.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 41.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	❓ Inconclusive	The PR description is comprehensive and well-structured, covering summary, rationale, detailed changes by package, test status, and out-of-scope items. However, it does not follow the required template structure with checklist items and explicit Testing/Changelog sections.	Follow the repository's PR description template: include the checklist items (contributing guide, title convention, testing), and fill in explicit Testing and Changelog sections rather than embedding them in free-form text.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly and specifically describes the main change: a user-facing rename of `maxDuration` to `maxComputeSeconds` across the SDK, which is the central objective of this changeset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

Create stacked PR
Commit on current branch

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch max-compute-seconds

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.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

🧹 Nitpick comments (2)

packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts (1)

1-20: ⚡ Quick win

Consider adding a test for 0 (falsy-but-valid) to guard against || regression.

The current suite doesn't cover maxComputeSeconds: 0 or maxDuration: 0. If a future refactor accidentally changes ?? to ||, the falsy-zero case would silently fall back to the other field (or undefined) and no test would catch it.

➕ Suggested additional test cases

   it("returns undefined when neither is set", () => {
     expect(resolveMaxComputeSeconds({})).toBeUndefined();
   });
+
+  it("returns 0 when maxComputeSeconds is explicitly 0", () => {
+    expect(resolveMaxComputeSeconds({ maxComputeSeconds: 0 })).toBe(0);
+  });
+
+  it("returns 0 when maxDuration is explicitly 0", () => {
+    expect(resolveMaxComputeSeconds({ maxDuration: 0 })).toBe(0);
+  });
 });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts` around lines 1 - 20,
Add tests to cover falsy-but-valid zero values so we don't regress to using ||
instead of ??; specifically, in the resolveMaxComputeSeconds test suite add
cases asserting that resolveMaxComputeSeconds({ maxComputeSeconds: 0 }) returns
0, resolveMaxComputeSeconds({ maxDuration: 0 }) returns 0, and that when both
are set and maxComputeSeconds is 0 (e.g., { maxComputeSeconds: 0, maxDuration:
999 }) the function still prefers maxComputeSeconds (returns 0); use the
resolveMaxComputeSeconds symbol to locate where to add these test cases.

packages/trigger-sdk/src/v3/config.ts (1)

12-20: ⚡ Quick win

Use the shared resolver here to avoid precedence drift.

defineConfig re-implements logic that already exists in resolveMaxComputeSeconds. Reusing the helper keeps all precedence behavior centralized.

♻️ Proposed refactor

 import type { TriggerConfig } from "@trigger.dev/core/v3";
+import { resolveMaxComputeSeconds } from "./maxComputeSeconds.js";
@@
-  const resolved = maxComputeSeconds ?? maxDuration;
+  const resolved = resolveMaxComputeSeconds({ maxComputeSeconds, maxDuration });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/trigger-sdk/src/v3/config.ts` around lines 12 - 20, The config
merging in defineConfig duplicates precedence logic — replace the manual
collapse of maxComputeSeconds/maxDuration with the shared helper by calling
resolveMaxComputeSeconds(config) (or the exported resolveMaxComputeSeconds
function) to compute the resolved value, then spread the rest of config and set
maxDuration from that resolved value when defined; update references to the
local consts ({ maxComputeSeconds, maxDuration, ...rest } and resolved) to
instead use the helper so all precedence behavior is centralized in
resolveMaxComputeSeconds.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/trigger-sdk/src/v3/config.ts`:
- Around line 12-20: The config merging in defineConfig duplicates precedence
logic — replace the manual collapse of maxComputeSeconds/maxDuration with the
shared helper by calling resolveMaxComputeSeconds(config) (or the exported
resolveMaxComputeSeconds function) to compute the resolved value, then spread
the rest of config and set maxDuration from that resolved value when defined;
update references to the local consts ({ maxComputeSeconds, maxDuration, ...rest
} and resolved) to instead use the helper so all precedence behavior is
centralized in resolveMaxComputeSeconds.

In `@packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts`:
- Around line 1-20: Add tests to cover falsy-but-valid zero values so we don't
regress to using || instead of ??; specifically, in the resolveMaxComputeSeconds
test suite add cases asserting that resolveMaxComputeSeconds({
maxComputeSeconds: 0 }) returns 0, resolveMaxComputeSeconds({ maxDuration: 0 })
returns 0, and that when both are set and maxComputeSeconds is 0 (e.g., {
maxComputeSeconds: 0, maxDuration: 999 }) the function still prefers
maxComputeSeconds (returns 0); use the resolveMaxComputeSeconds symbol to locate
where to add these test cases.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: afcef383-95ed-4c81-ba9b-5ae60c86a983

📥 Commits

Reviewing files that changed from the base of the PR and between 62e0066 and b25ed4c.

⛔ Files ignored due to path filters (2)

references/hello-world/src/trigger/example.ts is excluded by !references/**
references/hello-world/trigger.config.ts is excluded by !references/**

📒 Files selected for processing (14)

.changeset/max-compute-seconds.md
packages/cli-v3/templates/examples/schedule.mjs.template
packages/cli-v3/templates/examples/schedule.ts.template
packages/cli-v3/templates/examples/simple.mjs.template
packages/cli-v3/templates/examples/simple.ts.template
packages/cli-v3/templates/trigger.config.mjs.template
packages/cli-v3/templates/trigger.config.ts.template
packages/core/src/v3/config.ts
packages/core/src/v3/types/tasks.ts
packages/trigger-sdk/src/v3/config.test.ts
packages/trigger-sdk/src/v3/config.ts
packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
packages/trigger-sdk/src/v3/maxComputeSeconds.ts
packages/trigger-sdk/src/v3/shared.ts

📜 Review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)

GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 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 (7, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
GitHub Check: typecheck / typecheck

🧰 Additional context used

📓 Path-based instructions (15)

packages/trigger-sdk/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

In the Trigger.dev SDK (packages/trigger-sdk), prefer isomorphic code like fetch and ReadableStream instead of Node.js-specific code

Files:

packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
packages/trigger-sdk/src/v3/config.test.ts
packages/trigger-sdk/src/v3/maxComputeSeconds.ts
packages/trigger-sdk/src/v3/config.ts
packages/trigger-sdk/src/v3/shared.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead

Files:

packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
packages/trigger-sdk/src/v3/config.test.ts
packages/trigger-sdk/src/v3/maxComputeSeconds.ts
packages/core/src/v3/config.ts
packages/trigger-sdk/src/v3/config.ts
packages/core/src/v3/types/tasks.ts
packages/trigger-sdk/src/v3/shared.ts

**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use function declarations instead of default exports

Files:

packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
packages/trigger-sdk/src/v3/config.test.ts
packages/trigger-sdk/src/v3/maxComputeSeconds.ts
packages/core/src/v3/config.ts
packages/trigger-sdk/src/v3/config.ts
packages/core/src/v3/types/tasks.ts
packages/trigger-sdk/src/v3/shared.ts

**/*.{test,spec}.{ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use vitest for all tests in the Trigger.dev repository

Files:

packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
packages/trigger-sdk/src/v3/config.test.ts

**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)

**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries

Files:

packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
packages/trigger-sdk/src/v3/config.test.ts
packages/trigger-sdk/src/v3/maxComputeSeconds.ts
packages/core/src/v3/config.ts
packages/trigger-sdk/src/v3/config.ts
packages/core/src/v3/types/tasks.ts
packages/trigger-sdk/src/v3/shared.ts

packages/trigger-sdk/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (packages/trigger-sdk/CLAUDE.md)

Always import from @trigger.dev/sdk. Never use @trigger.dev/sdk/v3 (deprecated path alias)

Files:

packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
packages/trigger-sdk/src/v3/config.test.ts
packages/trigger-sdk/src/v3/maxComputeSeconds.ts
packages/trigger-sdk/src/v3/config.ts
packages/trigger-sdk/src/v3/shared.ts

packages/**/*.{ts,tsx,js}