feat(sdk): replace maxDuration with maxComputeSeconds (user-facing rename) [TRI-9126]#3533
feat(sdk): replace maxDuration with maxComputeSeconds (user-facing rename) [TRI-9126]#3533matt-aitken wants to merge 8 commits intomainfrom
maxDuration with maxComputeSeconds (user-facing rename) [TRI-9126]#3533Conversation
WalkthroughThis PR introduces Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsTimed out fetching pipeline failures after 30000ms Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts (1)
1-20: ⚡ Quick winConsider adding a test for
0(falsy-but-valid) to guard against||regression.The current suite doesn't cover
maxComputeSeconds: 0ormaxDuration: 0. If a future refactor accidentally changes??to||, the falsy-zero case would silently fall back to the other field (orundefined) 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 winUse the shared resolver here to avoid precedence drift.
defineConfigre-implements logic that already exists inresolveMaxComputeSeconds. 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
⛔ Files ignored due to path filters (2)
references/hello-world/src/trigger/example.tsis excluded by!references/**references/hello-world/trigger.config.tsis excluded by!references/**
📒 Files selected for processing (14)
.changeset/max-compute-seconds.mdpackages/cli-v3/templates/examples/schedule.mjs.templatepackages/cli-v3/templates/examples/schedule.ts.templatepackages/cli-v3/templates/examples/simple.mjs.templatepackages/cli-v3/templates/examples/simple.ts.templatepackages/cli-v3/templates/trigger.config.mjs.templatepackages/cli-v3/templates/trigger.config.ts.templatepackages/core/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/config.tspackages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/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.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/trigger-sdk/src/v3/config.tspackages/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.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/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.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/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.tspackages/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.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/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.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/trigger-sdk/src/v3/config.tspackages/trigger-sdk/src/v3/shared.ts
packages/**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
Use
pnpm run buildto verify changes in public packages (packages/*)
Files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.ts
**/*.test.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.test.{ts,tsx,js}: Use vitest exclusively for testing and never mock anything - use testcontainers instead
Place test files next to source files using the patternMyService.ts->MyService.test.ts
**/*.test.{ts,tsx,js}: Use vitest for unit testing and run tests withpnpm run test
Test files should live beside the files under test with descriptivedescribeanditblocks
Tests should avoid mocks or stubs and use helpers from@internal/testcontainerswhen Redis or Postgres are needed
Files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.ts
**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Use testcontainers with
redisTest,postgresTest, orcontainerTestfrom@internal/testcontainersfor testing with Redis/PostgreSQL dependencies
Files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.ts
{packages,integrations}/**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
When modifying any public package (
packages/*orintegrations/*), add a changeset usingpnpm run changeset:add
Files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.ts
{package.json,**/*.{ts,tsx,js}}
📄 CodeRabbit inference engine (CLAUDE.md)
Pin Zod to version 3.25.76 exactly across the entire monorepo - never use a different version or version range
Files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.ts
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx,js}: Import from@trigger.dev/coreusing subpaths only, never the root export
Always import tasks from@trigger.dev/sdk, never from@trigger.dev/sdk/v3or deprecatedclient.defineJob
Add crumbs to code using//@Crumbscomments or `// `#region` `@crumbsblocks for debug tracing during development
Files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.ts
**/*.{ts,tsx,js,jsx,json,md,css,scss}
📄 CodeRabbit inference engine (AGENTS.md)
Code formatting is enforced using Prettier. Run
pnpm run formatbefore committing
Files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
packages/core/src/v3/config.tspackages/core/src/v3/types/tasks.ts
packages/core/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (packages/core/CLAUDE.md)
Never import the root package (
@trigger.dev/core). Always use subpath imports such as@trigger.dev/core/v3,@trigger.dev/core/v3/utils,@trigger.dev/core/logger, or@trigger.dev/core/schemas
Files:
packages/core/src/v3/config.tspackages/core/src/v3/types/tasks.ts
🧠 Learnings (3)
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/core/src/v3/config.tspackages/trigger-sdk/src/v3/config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.ts
📚 Learning: 2026-03-31T21:37:27.212Z
Learnt from: isshaddad
Repo: triggerdotdev/trigger.dev PR: 3283
File: docs/migration-n8n.mdx:19-21
Timestamp: 2026-03-31T21:37:27.212Z
Learning: When reviewing code in `packages/trigger-sdk/src/v3`, treat `tasks.triggerAndWait()` and `tasks.batchTriggerAndWait()` as real exported APIs. They are defined in `shared.ts` and re-exported via the `tasks` object in `tasks.ts`, and they take the task ID string as their first argument (not a task instance). This is distinct from the instance methods `yourTask.triggerAndWait()` and `yourTask.batchTriggerAndWait()`. Do not flag calls to `tasks.triggerAndWait()` or `tasks.batchTriggerAndWait()` as non-existent or incorrectly invoked.
Applied to files:
packages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/trigger-sdk/src/v3/config.tspackages/trigger-sdk/src/v3/shared.ts
🔇 Additional comments (11)
packages/cli-v3/templates/trigger.config.ts.template (1)
7-10: Same stale doc link as intrigger.config.mjs.template.Line 9's
// See https://trigger.dev/docs/runs/max-durationhas the same issue noted in the.mjscounterpart — the URL slug will become stale once the docs page is updated for themaxComputeSecondsrename.packages/cli-v3/templates/examples/schedule.ts.template (1)
7-8: LGTM.Straightforward rename with updated inline comment.
packages/cli-v3/templates/examples/simple.ts.template (1)
5-6: LGTM.packages/cli-v3/templates/examples/schedule.mjs.template (1)
7-8: LGTM.packages/trigger-sdk/src/v3/config.test.ts (1)
1-29: LGTM.Good coverage of all precedence cases, including the important "strips
maxComputeSeconds" assertion at Line 25–28. The type-cast approach to verify key absence from the returned type is idiomatic here.packages/cli-v3/templates/examples/simple.mjs.template (1)
5-6: LGTM..changeset/max-compute-seconds.md (1)
1-8: Changeset scope and messaging look correct.Package bump coverage and the migration/precedence note are clear and consistent with the implementation intent.
packages/trigger-sdk/src/v3/maxComputeSeconds.ts (1)
8-13: Helper implementation is clean and correct.The nullish-coalescing precedence exactly matches the intended
maxComputeSeconds-first behavior.packages/core/src/v3/config.ts (1)
168-189: Type-level rename/deprecation contract looks good.The new field plus explicit deprecation/preference semantics preserve backward compatibility while steering users to the clearer option name.
packages/core/src/v3/types/tasks.ts (1)
274-289: Task and trigger option typing updates are consistent.Both surfaces now document the rename and precedence rule clearly, which helps avoid ambiguity for consumers.
Also applies to: 888-907
packages/trigger-sdk/src/v3/shared.ts (1)
34-35: Resolution wiring is consistently applied across all trigger paths.Nice job applying
resolveMaxComputeSecondsthrough task metadata registration plus single/batch, wait/non-wait, and streaming flows.Also applies to: 239-240, 371-372, 647-648, 904-905, 1163-1164, 1425-1426, 1827-1828, 1880-1881, 1930-1931, 1982-1983, 2034-2035, 2095-2096, 2145-2146, 2229-2230, 2402-2403, 2504-2505
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
🦋 Changeset detectedLatest commit: 5d8e259 The changes in this PR will be included in the next version bump. This PR includes changesets to release 29 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 |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/core/src/v3/errors.ts (1)
741-746: ⚡ Quick win
exceptionEventEnhancerhas no case forMAX_DURATION_EXCEEDED.
taskRunErrorEnhancergains the new link automatically via its catch-allgetPrettyTaskRunError(error.code)spread, butexceptionEventEnhanceronly explicitly handles a handful of codes (OOM, SIGTERM). If aMAX_DURATION_EXCEEDEDevent flows through the exception path, it won't receive the docs link.For consistency with how
TASK_RUN_STALLED_EXECUTINGandTASK_RUN_UNCAUGHT_EXCEPTIONare handled inprettyInternalErrors— link-only entries that feedgetPrettyExceptionEvent— adding a case alongside lines 954-961 would close this gap:🔧 Suggested addition to
exceptionEventEnhancercase TaskRunErrorCodes.TASK_PROCESS_MAYBE_OOM_KILLED: case TaskRunErrorCodes.TASK_PROCESS_OOM_KILLED: case TaskRunErrorCodes.TASK_PROCESS_SIGTERM: { return { ...exception, ...getPrettyExceptionEvent(exception.type), }; } + case TaskRunErrorCodes.MAX_DURATION_EXCEEDED: { + return { + ...exception, + ...getPrettyExceptionEvent(exception.type), + }; + }🤖 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/core/src/v3/errors.ts` around lines 741 - 746, exceptionEventEnhancer is missing a case for MAX_DURATION_EXCEEDED so those events don't get the docs link; add a new case in exceptionEventEnhancer (alongside the existing OOM/SIGTERM cases) that maps MAX_DURATION_EXCEEDED to the same link-only shape used by prettyInternalErrors and that feeds getPrettyExceptionEvent (i.e., create an entry for MAX_DURATION_EXCEEDED that references links.docs.maxDuration so the exception path attaches the "How to set maxComputeSeconds (maxDuration)" link).
🤖 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/core/src/v3/errors.ts`:
- Around line 741-746: exceptionEventEnhancer is missing a case for
MAX_DURATION_EXCEEDED so those events don't get the docs link; add a new case in
exceptionEventEnhancer (alongside the existing OOM/SIGTERM cases) that maps
MAX_DURATION_EXCEEDED to the same link-only shape used by prettyInternalErrors
and that feeds getPrettyExceptionEvent (i.e., create an entry for
MAX_DURATION_EXCEEDED that references links.docs.maxDuration so the exception
path attaches the "How to set maxComputeSeconds (maxDuration)" link).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5868cfff-6698-4c6c-980d-3308f1407ad6
📒 Files selected for processing (2)
packages/core/src/v3/errors.tspackages/core/src/v3/links.ts
✅ Files skipped from review due to trivial changes (1)
- packages/core/src/v3/links.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). (29)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: units / e2e-webapp / 🧪 E2E Tests: Webapp
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: sdk-compat / Bun Runtime
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: Analyze (javascript-typescript)
🧰 Additional context used
📓 Path-based instructions (10)
**/*.{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/core/src/v3/errors.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
packages/core/src/v3/errors.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Files:
packages/core/src/v3/errors.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/core/src/v3/errors.ts
packages/core/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (packages/core/CLAUDE.md)
Never import the root package (
@trigger.dev/core). Always use subpath imports such as@trigger.dev/core/v3,@trigger.dev/core/v3/utils,@trigger.dev/core/logger, or@trigger.dev/core/schemas
Files:
packages/core/src/v3/errors.ts
packages/**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
Use
pnpm run buildto verify changes in public packages (packages/*)
Files:
packages/core/src/v3/errors.ts
{packages,integrations}/**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
When modifying any public package (
packages/*orintegrations/*), add a changeset usingpnpm run changeset:add
Files:
packages/core/src/v3/errors.ts
{package.json,**/*.{ts,tsx,js}}
📄 CodeRabbit inference engine (CLAUDE.md)
Pin Zod to version 3.25.76 exactly across the entire monorepo - never use a different version or version range
Files:
packages/core/src/v3/errors.ts
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx,js}: Import from@trigger.dev/coreusing subpaths only, never the root export
Always import tasks from@trigger.dev/sdk, never from@trigger.dev/sdk/v3or deprecatedclient.defineJob
Add crumbs to code using//@Crumbscomments or `// `#region` `@crumbsblocks for debug tracing during development
Files:
packages/core/src/v3/errors.ts
**/*.{ts,tsx,js,jsx,json,md,css,scss}
📄 CodeRabbit inference engine (AGENTS.md)
Code formatting is enforced using Prettier. Run
pnpm run formatbefore committing
Files:
packages/core/src/v3/errors.ts
🧠 Learnings (2)
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
packages/core/src/v3/errors.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
packages/core/src/v3/errors.ts
🔇 Additional comments (1)
packages/core/src/v3/errors.ts (1)
741-746: No action needed —links.docs.maxDurationis properly defined.The link key is correctly configured at
packages/core/src/v3/links.ts:29with the value"https://trigger.dev/docs/runs/max-duration". The newMAX_DURATION_EXCEEDEDentry will function as intended.
- 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.
If a user exports a trigger.config plain object without going through defineConfig() (TypeScript allows it), validation previously rejected the new maxComputeSeconds field with an error mentioning maxDuration. Mirror the SDK boundary's resolution at the CLI boundary so downstream internals (which still read maxDuration) keep working.
matt-aitken
force-pushed
the
max-compute-seconds
branch
from
9ac5175 to
5d8e259
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@packages/cli-v3/src/config.ts`:
- Around line 347-353: The current check using resolvedMaxDuration only rejects
falsy values and allows values 1..4; update the validation around
resolvedMaxDuration (derived from config.maxComputeSeconds) to ensure it is a
number >= 5 before assigning to config.maxDuration, and if it is missing or less
than 5 throw the same Error with the message that "maxComputeSeconds" is
required and must be at least 5 seconds; adjust the branch that currently throws
to cover both undefined/null and values < 5 so resolvedMaxDuration is only
assigned to config.maxDuration when valid.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: eaa8c333-7fc3-41cb-bdb8-30544dd15c52
⛔ Files ignored due to path filters (2)
references/hello-world/src/trigger/example.tsis excluded by!references/**references/hello-world/trigger.config.tsis excluded by!references/**
📒 Files selected for processing (17)
.changeset/max-compute-seconds.mdpackages/cli-v3/src/config.tspackages/cli-v3/templates/examples/schedule.mjs.templatepackages/cli-v3/templates/examples/schedule.ts.templatepackages/cli-v3/templates/examples/simple.mjs.templatepackages/cli-v3/templates/examples/simple.ts.templatepackages/cli-v3/templates/trigger.config.mjs.templatepackages/cli-v3/templates/trigger.config.ts.templatepackages/core/src/v3/config.tspackages/core/src/v3/errors.tspackages/core/src/v3/links.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/config.test.tspackages/trigger-sdk/src/v3/config.tspackages/trigger-sdk/src/v3/maxComputeSeconds.test.tspackages/trigger-sdk/src/v3/maxComputeSeconds.tspackages/trigger-sdk/src/v3/shared.ts
✅ Files skipped from review due to trivial changes (6)
- packages/core/src/v3/links.ts
- packages/cli-v3/templates/examples/schedule.mjs.template
- packages/trigger-sdk/src/v3/maxComputeSeconds.test.ts
- packages/cli-v3/templates/examples/schedule.ts.template
- .changeset/max-compute-seconds.md
- packages/trigger-sdk/src/v3/config.test.ts
🚧 Files skipped from review as they are similar to previous changes (9)
- packages/cli-v3/templates/examples/simple.mjs.template
- packages/trigger-sdk/src/v3/maxComputeSeconds.ts
- packages/cli-v3/templates/examples/simple.ts.template
- packages/cli-v3/templates/trigger.config.mjs.template
- packages/core/src/v3/types/tasks.ts
- packages/core/src/v3/config.ts
- packages/trigger-sdk/src/v3/shared.ts
- packages/trigger-sdk/src/v3/config.ts
- packages/core/src/v3/errors.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). (27)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- 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 (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / e2e-webapp / 🧪 E2E Tests: Webapp
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: sdk-compat / Bun Runtime
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: typecheck / typecheck
🧰 Additional context used
📓 Path-based instructions (8)
**/*.{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/cli-v3/src/config.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Files:
packages/cli-v3/src/config.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/cli-v3/src/config.ts
packages/**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
Use
pnpm run buildto verify changes in public packages (packages/*)
Files:
packages/cli-v3/src/config.ts
{packages,integrations}/**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
When modifying any public package (
packages/*orintegrations/*), add a changeset usingpnpm run changeset:add
Files:
packages/cli-v3/src/config.ts
{package.json,**/*.{ts,tsx,js}}
📄 CodeRabbit inference engine (CLAUDE.md)
Pin Zod to version 3.25.76 exactly across the entire monorepo - never use a different version or version range
Files:
packages/cli-v3/src/config.ts
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx,js}: Import from@trigger.dev/coreusing subpaths only, never the root export
Always import tasks from@trigger.dev/sdk, never from@trigger.dev/sdk/v3or deprecatedclient.defineJob
Add crumbs to code using//@Crumbscomments or `// `#region` `@crumbsblocks for debug tracing during development
Files:
packages/cli-v3/src/config.ts
**/*.{ts,tsx,js,jsx,json,md,css,scss}
📄 CodeRabbit inference engine (AGENTS.md)
Code formatting is enforced using Prettier. Run
pnpm run formatbefore committing
Files:
packages/cli-v3/src/config.ts
🧠 Learnings (2)
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
packages/cli-v3/src/config.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
packages/cli-v3/src/config.ts
🔇 Additional comments (1)
packages/cli-v3/templates/trigger.config.ts.template (1)
7-10: Rename is consistent and clear.
maxComputeSecondsis correctly reflected in both the inline guidance and template config value.
| const resolvedMaxDuration = config.maxComputeSeconds ?? config.maxDuration; | ||
| if (!resolvedMaxDuration) { | ||
| throw new Error( | ||
| `The "maxDuration" trigger.config option is now required, and must be at least 5 seconds.` | ||
| `The "maxComputeSeconds" trigger.config option is now required, and must be at least 5 seconds.` | ||
| ); | ||
| } | ||
| config.maxDuration = resolvedMaxDuration; |
There was a problem hiding this comment.
Lower-bound validation is missing for maxComputeSeconds.
On Line 348, if (!resolvedMaxDuration) only rejects falsy values. Values 1..4 pass, even though the error on Line 350 states the minimum is 5 seconds.
Proposed fix
- const resolvedMaxDuration = config.maxComputeSeconds ?? config.maxDuration;
- if (!resolvedMaxDuration) {
+ const resolvedMaxDuration = config.maxComputeSeconds ?? config.maxDuration;
+ if (
+ typeof resolvedMaxDuration !== "number" ||
+ !Number.isFinite(resolvedMaxDuration) ||
+ resolvedMaxDuration < 5
+ ) {
throw new Error(
`The "maxComputeSeconds" trigger.config option is now required, and must be at least 5 seconds.`
);
}
config.maxDuration = resolvedMaxDuration;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const resolvedMaxDuration = config.maxComputeSeconds ?? config.maxDuration; | |
| if (!resolvedMaxDuration) { | |
| throw new Error( | |
| `The "maxDuration" trigger.config option is now required, and must be at least 5 seconds.` | |
| `The "maxComputeSeconds" trigger.config option is now required, and must be at least 5 seconds.` | |
| ); | |
| } | |
| config.maxDuration = resolvedMaxDuration; | |
| const resolvedMaxDuration = config.maxComputeSeconds ?? config.maxDuration; | |
| if ( | |
| typeof resolvedMaxDuration !== "number" || | |
| !Number.isFinite(resolvedMaxDuration) || | |
| resolvedMaxDuration < 5 | |
| ) { | |
| throw new Error( | |
| `The "maxComputeSeconds" trigger.config option is now required, and must be at least 5 seconds.` | |
| ); | |
| } | |
| config.maxDuration = resolvedMaxDuration; |
🤖 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/cli-v3/src/config.ts` around lines 347 - 353, The current check
using resolvedMaxDuration only rejects falsy values and allows values 1..4;
update the validation around resolvedMaxDuration (derived from
config.maxComputeSeconds) to ensure it is a number >= 5 before assigning to
config.maxDuration, and if it is missing or less than 5 throw the same Error
with the message that "maxComputeSeconds" is required and must be at least 5
seconds; adjust the branch that currently throws to cover both undefined/null
and values < 5 so resolvedMaxDuration is only assigned to config.maxDuration
when valid.
1 participant
Summary
User-facing rename of
maxDuration→maxComputeSecondsondefineConfig, task definitions, and trigger options. The legacymaxDurationfield stays in place but is JSDoc-deprecated; if both are set,maxComputeSecondswins. Internal SDK/CLI/run-engine code (~380 references tomaxDurationInSeconds) is not touched — translation happens at the user-facing boundary only.Linear: TRI-9126
Why
maxDurationis in seconds but users frequently pass milliseconds by mistake (e.g.maxDuration: 300000thinking "5 minutes"). The new name makes the unit unambiguous at the call site.What changed
@trigger.dev/core— addedmaxComputeSeconds?: numberand JSDoc-deprecatedmaxDurationonTriggerConfig,CommonTaskOptions, andTriggerOptions.@trigger.dev/sdk—defineConfigcollapsesmaxComputeSeconds ?? maxDurationinto the existingmaxDurationslot. NewresolveMaxComputeSecondshelper applied at all 16 user-input sites inshared.ts(task definitions,trigger,triggerAndWait,batchTrigger,batchTriggerAndWait).trigger.devCLI — six init templates updated (trigger.config.ts/.mjs,examples/simple.ts/.mjs,examples/schedule.ts/.mjs).references/hello-world—trigger.config.tsandexample.ts(maxDurationTaskper-task value +maxDurationParentTaskper-trigger override) updated for manual testing.defineConfigand the resolver helper.@trigger.dev/core,@trigger.dev/sdk,trigger.dev.Out of scope
maxDurationInSecondsfield (DB, ClickHouse, run engine, MarQS, dashboard presenters) — unchanged.getMaxDuration()precedence helper inpackages/core/src/v3/isomorphic/maxDuration.ts— unchanged.docs/— separate dedicated pass.rules/and.claude/skills/trigger-dev-tasks/— explicitly excluded by repo conventions.maxDurationis used — out of scope; deprecation is JSDoc-only for now.Test plan
pnpm run build --filter @trigger.dev/core— cleanpnpm run build --filter @trigger.dev/sdk— cleancd references/hello-world && pnpm exec trigger dev, triggermax-durationtask, confirm 5s timeout still kicks inmax-duration-parentand confirm{ maxComputeSeconds: timeout.None }overrides the task's per-task limittrigger initin a temp dir, confirm generatedtrigger.config.tsand example task usemaxComputeSeconds🤖 Generated with Claude Code