Skip to content

fix(core): use zod/v4 for the snapshot route schema so warm starts work on zod 3 projects - #4972

Merged
carderne merged 1 commit into
mainfrom
fix/core-snapshot-route-zod-v4
Sep 22, 2026
Merged

carderne merged 1 commit into
mainfrom
fix/core-snapshot-route-zod-v4

Conversation

@d-cs

@d-cs d-cs commented Sep 22, 2026

Copy link
Copy Markdown
Collaborator

Summary

Deployments built with 4.6.0 to 4.6.3 in projects where zod resolves to a 3.x release could not warm start. Every run handed to a warm runner made the runner exit before it started the attempt; the run then waited until the platform's heartbeat redrive requeued it and it started cold, a few minutes late. Cold starts were unaffected, which is why this surfaced as delayed starts rather than errors.

Root cause

The zod v4 migration (#4039) moved core's schemas to zod/v4. snapshotRoute.ts landed shortly after, still importing the Zod 3 API from "zod", and SnapshotRouteWire is composed into DequeuedMessage and the worker attempt request bodies. Zod 4 rejects a Zod 3 schema inside a Zod 4 object at parse time, regardless of the input:

Invalid element at key "snapshotRoute": expected a Zod schema

Inside the monorepo the root zod resolves to 4.x, so nothing failed here. In a user's image with zod 3.x installed, the warm-start client's DequeuedMessage.parse() threw on every run and the controller exited.

Fix

One import: snapshotRoute.ts now uses zod/v4. The existing Zod 3 root compatibility test gains a case that bundles DequeuedMessage and WorkerApiRunAttemptStartRequestBody against a Zod 3 root and parses them; it fails on main and passes here. Also verified by packing the built package and parsing a DequeuedMessage with zod@3.25.76 installed.

…rk on zod 3 projects

The snapshot route schema was created with the Zod 3 API and composed into
Zod 4 objects (DequeuedMessage and the worker attempt request bodies). When a
project resolves "zod" to a 3.x release, Zod 4 rejects the composed schema at
parse time, so the runner's warm-start client threw on every dispatched run
and exited. The run then waited for the heartbeat redrive before starting
cold. Extends the Zod 3 root compatibility test to cover these schemas.
@changeset-bot

changeset-bot Bot commented Sep 22, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 1906c00

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 27 packages
Name Type
@trigger.dev/core Patch
@trigger.dev/build Patch
trigger.dev Patch
@trigger.dev/python Patch
@trigger.dev/redis-worker Patch
@trigger.dev/schema-to-json Patch
@trigger.dev/sdk Patch
@internal/clickhouse Patch
@internal/llm-model-catalog Patch
@internal/metrics-pipeline Patch
@trigger.dev/rbac Patch
@internal/redis Patch
@internal/replication Patch
@internal/run-engine Patch
@internal/run-store Patch
@internal/schedule-engine Patch
@internal/tracing Patch
@internal/webhook-engine Patch
@internal/webhook-sources Patch
@internal/dashboard-agent Patch
@internal/cache Patch
@trigger.dev/react-hooks Patch
@trigger.dev/rsc Patch
@trigger.dev/database Patch
@trigger.dev/otlp-importer Patch
@trigger.dev/sso Patch
@internal/testcontainers Patch

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

@d-cs
d-cs marked this pull request as draft September 22, 2026 16:25

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

Devin Review

@coderabbitai

coderabbitai Bot commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 5bf0ce57-d25f-4e26-8fcd-f67c136ff5b8

📥 Commits

Reviewing files that changed from the base of the PR and between 562c943 and 1906c00.

📒 Files selected for processing (3)
  • .changeset/snapshot-route-zod-v4.md
  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
  • packages/core/src/v3/schemas/snapshotRoute.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📜 Recent review details
⏰ Context from checks skipped due to timeout. (30)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (24, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (23, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (21, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (9, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (15, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (17, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (18, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (16, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (14, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (19, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (10, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (11, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (13, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (12, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (7, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (20, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (6, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (4, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (8, 24)
  • GitHub Check: webapp / 🧪 Unit Tests: Webapp (5, 24)
  • GitHub Check: packages / 🧪 Unit Tests: Packages (3, 3)
  • GitHub Check: packages / 🧪 Unit Tests: Packages (1, 3)
  • GitHub Check: e2e-webapp / 🧪 E2E Tests: Webapp (1, 2)
  • GitHub Check: packages / 🧪 Unit Tests: Packages (2, 3)
  • GitHub Check: internal / 🧪 Unit Tests: Internal (1)
  • GitHub Check: e2e / 🧪 CLI v3 tests (warp-windows-latest-x64-8x - pnpm)
  • GitHub Check: e2e / 🧪 CLI v3 tests (warp-windows-latest-x64-8x - npm)
  • GitHub Check: internal / 🧪 Unit Tests: Internal (2)
  • GitHub Check: e2e-webapp / 🧪 E2E Tests: Webapp (2, 2)
  • GitHub Check: Analyze (javascript-typescript)
🧰 Additional context used
📓 Path-based instructions (7)
**Public packages** (`packages/*`): Use `build`.

📄 CodeRabbit inference engine (AGENTS.md)

Files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
  • packages/core/src/v3/schemas/snapshotRoute.ts
Use zod for validation in packages/core and apps/webapp

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

Files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
  • packages/core/src/v3/schemas/snapshotRoute.ts
Never import the root package (`@trigger.dev/core`).

📄 CodeRabbit inference engine (packages/core/CLAUDE.md)

Files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
  • packages/core/src/v3/schemas/snapshotRoute.ts
Use vitest for all tests in the Trigger.dev repository

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

Files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
Use function declarations instead of default exports

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

Files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
  • packages/core/src/v3/schemas/snapshotRoute.ts
Use types over interfaces for TypeScript Avoid using enums; prefer string unions or const objects instead

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

Files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
  • packages/core/src/v3/schemas/snapshotRoute.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 metr...

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

Files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
  • packages/core/src/v3/schemas/snapshotRoute.ts
🧠 Learnings (1)
📚 Learning: 2026-06-16T09:19:47.637Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3960
File: apps/webapp/test/prismaInfrastructureErrorCapture.test.ts:0-0
Timestamp: 2026-06-16T09:19:47.637Z
Learning: In this repo’s Vitest setup, `vitest.config.ts` uses `globals: true`, so identifiers like `vi`, `describe`, `it`, and `expect` are available as globals in Vitest test files. During code review, do not flag missing `vi`/`describe`/`it`/`expect` imports as a runtime error or correctness issue when they’re used in `*.test.ts/tsx` or `*.spec.ts/tsx` files. Explicit imports are still preferred for consistency, but they’re not required for runtime behavior.

Applied to files:

  • packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts
🔇 Additional comments (3)
packages/core/src/v3/schemas/snapshotRoute.ts (1)

1-1: LGTM!

packages/core/src/v3/schemas/schemaCompositionCompatibility.test.ts (1)

95-172: LGTM!

.changeset/snapshot-route-zod-v4.md (1)

1-5: LGTM!


Walkthrough

The snapshot-route schemas now import zod/v4. A compatibility test bundles and parses worker schemas with Zod 3 and Zod 4 mappings. A patch changeset documents the warm-start parsing fix for affected deployments.

Priority: ➖ Normal

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 1906c

Affected warm starts should parse correctly across supported Zod versions, with no remaining merge-blocking risk identified.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…
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.
Title check ✅ Passed The title clearly identifies the main change: using zod/v4 for the snapshot route schema to fix warm starts for projects using Zod 3.
Description check ✅ Passed The description clearly explains the affected versions, root cause, fix, and validation. It does not follow every template section, because it omits the issue reference, checklist, and explicit Testin…
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

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.

@carderne
carderne marked this pull request as ready for review September 22, 2026 16:51
@carderne
carderne added this pull request to the merge queue Sep 22, 2026
Merged via the queue into main with commit 21146b1 Sep 22, 2026
126 checks passed
@carderne
carderne deleted the fix/core-snapshot-route-zod-v4 branch September 22, 2026 17:15
@github-actions github-actions Bot mentioned this pull request Sep 22, 2026
birhantprkc pushed a commit to birhantprkc/trigger.dev that referenced this pull request Oct 1, 2026
## Summary
6 new features, 17 improvements, 13 bug fixes.

## Improvements
- Chat agents can now scope concurrency per session. Pass
`concurrencyKey` (for example, your chat ID or tenant ID) and
trigger-time named limits via `triggerConfig.concurrency` when starting
a chat session, from `chat.createStartSessionAction`, the `AgentChat`
client, or a handover. Keys are never defaulted, so a session without
one shares the task's keyless pool.
([`ea9758117`](triggerdotdev@ea97581))
  
  ```ts
  const start = chat.createStartSessionAction("support-chat", {
  triggerConfig: { concurrencyKey: user.id },
  });
  ```
- Concurrency limits can now be paused and resumed, just like queues:
`concurrencyLimits.pause(name)` stops every run holding the limit from
being dequeued while keeping its configured bounds, and
`concurrencyLimits.resume(name)` starts them again.
([`fa94febb6`](triggerdotdev@fa94feb))
  
  ```ts
  import { concurrencyLimits } from "@trigger.dev/sdk";
  
  await concurrencyLimits.pause("openai");
  await concurrencyLimits.resume("openai");
  ```
- Control a task's concurrency with the new `concurrency` option, and
share limits across tasks with named concurrency limits. An inline shape
caps the task itself; `concurrencyLimit()` declares a limit any task can
hold (up to two named limits per task), and a trigger call can switch a
run's named limits with its own `concurrency` option.
([`ea9758117`](triggerdotdev@ea97581))
  
  ```ts
  import { concurrencyLimit, task } from "@trigger.dev/sdk";
  
export const openaiLimit = concurrencyLimit({ name: "openai", total: 25
});
  
  export const generateSummary = task({
  id: "generate-summary",
  concurrency: [{ perKey: 1, total: 5 }, openaiLimit],
  run: async (payload) => {},
  });
  ```
  
`perKey` caps each `concurrencyKey` pool and `total` caps across
everything, keys or not. The queue-level `concurrencyLimit` option keeps
working unchanged and is deprecated in favor of `concurrency`.
Enforcement happens server-side; servers without support accept the
option but do not enforce it yet.
  
Manage limits at runtime with the new `concurrencyLimits` namespace:
`list()` and `retrieve(name)` report each limit's bounds plus its live
`running` and `queued` counts, `override(name, { perKey, total })`
changes only the given bounds (overriding `total` to `0` pauses the
limit), and `reset(name)` restores the declared values.
  
Queue reads (`queues.list()` and `queues.retrieve()`) now report a
`version` that discriminates the shape: `V1` queues keep today's fields
(their own `concurrencyLimit` and its override state), while `V2` queues
(tasks declared with `concurrency`) carry no queue-level concurrency,
since their limits are read and overridden through `concurrencyLimits`
(a task's inline limit under its derived `task/<task-id>` name).
Existing reads keep compiling: a `V2` queue reports `concurrencyLimit`
as null and `concurrency` as undefined.
- Chat streams now report `Stream stalled: no records received` after
five retries of a connected stream that sends no records. Network
failures and browser wakeups retain automatic recovery. Healthy tool
calls with no records for about six minutes also reach this silence
limit. Watch subscriptions remain unlimited, and caller cancellation
still closes cleanly.
([triggerdotdev#4949](triggerdotdev#4949))
- Webhook verifier artifacts can now declare the provider's response
contract as data: a handshake `respondStatus`, the status codes returned
for accepted deliveries and rejected signatures, and a GET verification
flow (`getHandshake`) for providers that confirm a callback URL with a
challenge. HMAC verifiers can read the timestamp from a body field,
which the Linear provider config uses for its replay window, and the
dashboard's test-send re-signs a recorded sample as of now so it passes
that window.
([`5f54fb27f`](triggerdotdev@5f54fb2))
- Add an optional `onSettled` callback to
`TriggerChatTransport.sendAction()` so callers can confirm that their
action's input was processed, independently of whether the response
stream closes.
([triggerdotdev#4956](triggerdotdev#4956))
- Chat agents now return to a durable wait when a session wake does not
deliver a matching message. This prevents resumed runs from staying
active until their maximum duration and preserves the configured turn
timeout across repeated wakes.
([`e6ec2c4e8`](triggerdotdev@e6ec2c4))
- Deprecate `queues.overrideConcurrencyLimit` and
`queues.resetConcurrencyLimit`. These operate on the legacy model where
a queue carried its own concurrency limit; declare concurrency with the
task `concurrency` option and manage it with
`concurrencyLimits.override` and `concurrencyLimits.reset` instead.
([`414e5a268`](triggerdotdev@414e5a2))
- Steering messages now remain in context across agent steps and keep
their original position in saved conversations, including custom
response data written between steps.
([`5619acf26`](triggerdotdev@5619acf))
- Set up a new Trigger.dev account from the CLI. Login can prefill an
email address, save the user's full name after authorization, and resume
authorization later, while `init` can create the first organization,
activate its Free plan, and create the first project before scaffolding
the app.
([`fb3b26d4f`](triggerdotdev@fb3b26d))
- Added a `submit_feedback` MCP tool so coding agents can report a
confusing tool error, a docs mismatch, or a missing capability without
the user having to file it by hand. Turn it off with `--skip-telemetry`
or `TRIGGER_TELEMETRY_DISABLED`; the tool is hidden while it is off.
([`9d38ff508`](triggerdotdev@9d38ff5))
- Authenticate `trigger promote` with environment API keys supplied
through `TRIGGER_ACCESS_TOKEN`. Environment API key commands now use the
saved profile API URL when no explicit override is provided.
([`562c9433a`](triggerdotdev@562c943))
- Convert Zod 4 `z.date()` fields to date-time strings in JSON Schema
without weakening validation for other unsupported types. This prevents
MCP tool discovery from failing when a tool input schema contains a
date.
([`f8babdf9b`](triggerdotdev@f8babdf))

## Bug fixes
- Fix stale and empty project environment values in `trigger dev`, and
support empty values in `syncEnvVars()`.
([`f384e8334`](triggerdotdev@f384e83))
- Fixes warm starts silently failing for deployments built with 4.6.0 to
4.6.3 in projects that resolve `zod` to a 3.x release. The runner could
not parse the run handed to it by the warm-start service and exited,
leaving the run waiting until the platform redrove it a few minutes
later and started it cold. Redeploy to pick up the fix.
([triggerdotdev#4972](triggerdotdev#4972))
- Fix a ~6-second delay between a task finishing and its run completing
(and a ~31-second delay when cancelling a run) in projects that use zod
4.4 or newer. Run cost and billed usage was not impacted by this issue.
([triggerdotdev#4980](triggerdotdev#4980))
- Fix Windows deploys failing at indexing with `Cannot find module` on a
percent-encoded path when the project directory contains spaces or
non-ASCII characters.
([`b32c1d157`](triggerdotdev@b32c1d1))

## Server changes

These changes affect the self-hosted Docker image and Trigger.dev Cloud:

- One concurrency key with a large backlog no longer holds up runs
waiting on other keys on the same queue.
([triggerdotdev#4367](triggerdotdev#4367))
- API rate limit usage is now recorded per environment in the `metrics`
table as `api.rate_limit.allowed`, `api.rate_limit.denied`,
`api.rate_limit.remaining_min` and the limit itself
(`api.rate_limit.limit.per_second` and `api.rate_limit.limit.burst`), so
you can chart requests against your limit and 429s over time on the
Query page and dashboards.
- Archive queues you no longer use from the Concurrency page. Archived
queues are hidden from the list and no longer count towards allocated
concurrency.
- Automatically archive preview branches after a configurable period
without deployments, with protected branch names and a preview of
affected branches.
- Download a session’s original saved transcript file from the session
inspector.
- Organization Owners and Admins can now choose, in Settings under
Support Access, whether Trigger.dev support can open their dashboard
directly or only after an Owner or Admin approves a request, with each
approval lasting 7 days.
- Allocating extra concurrency to environments now requires billing
permissions, the same as purchasing it. Allocation changes are also
applied atomically, so simultaneous edits can no longer exceed your
purchased concurrency.
- Changing your account email address now sends a confirmation link to
the new address; the change only takes effect once that link is opened.
Requesting a magic link no longer creates an account until the link is
used.
- Removed the organization-wide Node.js 21 deprecation banner while
keeping runtime upgrade guidance in Projects settings.
- Creating a project now asks only for its name.
- Prevent batch waits from remaining suspended when batch completion is
briefly interrupted
- Reject batch-and-wait requests when the parent run belongs to another
environment
- Keep dashboard pages visible during network interruptions, with a
disconnected banner and a Refresh button instead of a full-page error.
- Allow deployments to replace declarative schedules at the schedule
limit when the resulting set stays within quota.
- "Deploy now" now tells you when the branch doesn't exist on GitHub
instead of showing a generic error, and a first deployment no longer
flags a harmless build-cache message as an error.
- Support empty-string environment values across the dashboard, API, and
Vercel sync behind a feature flag, disabled by default.
- Fixed a bug where a burst of telemetry could leave OpenTelemetry
ingest rejecting every batch for a long time. Batches that wait too long
are now dropped individually instead of restarting the processing
workers, so ingest recovers as soon as the burst passes.
- Keep scheduled task "Last run" times stable across unchanged
deployments and align them with configured schedule windows.
- Team members and pending invites on the organization Team page are now
listed in alphabetical order.

<details>
<summary>Raw changeset output</summary>

# Releases
## @trigger.dev/core@4.7.0

### Minor Changes

- Chat agents can now scope concurrency per session. Pass
`concurrencyKey` (for example, your chat ID or tenant ID) and
trigger-time named limits via `triggerConfig.concurrency` when starting
a chat session, from `chat.createStartSessionAction`, the `AgentChat`
client, or a handover. Keys are never defaulted, so a session without
one shares the task's keyless pool.
([`ea9758117`](triggerdotdev@ea97581))

  ```ts
  const start = chat.createStartSessionAction("support-chat", {
    triggerConfig: { concurrencyKey: user.id },
  });
  ```

- Concurrency limits can now be paused and resumed, just like queues:
`concurrencyLimits.pause(name)` stops every run holding the limit from
being dequeued while keeping its configured bounds, and
`concurrencyLimits.resume(name)` starts them again.
([`fa94febb6`](triggerdotdev@fa94feb))

  ```ts
  import { concurrencyLimits } from "@trigger.dev/sdk";

  await concurrencyLimits.pause("openai");
  await concurrencyLimits.resume("openai");
  ```

- Control a task's concurrency with the new `concurrency` option, and
share limits across tasks with named concurrency limits. An inline shape
caps the task itself; `concurrencyLimit()` declares a limit any task can
hold (up to two named limits per task), and a trigger call can switch a
run's named limits with its own `concurrency` option.
([`ea9758117`](triggerdotdev@ea97581))

  ```ts
  import { concurrencyLimit, task } from "@trigger.dev/sdk";

export const openaiLimit = concurrencyLimit({ name: "openai", total: 25
});

  export const generateSummary = task({
    id: "generate-summary",
    concurrency: [{ perKey: 1, total: 5 }, openaiLimit],
    run: async (payload) => {},
  });
  ```

`perKey` caps each `concurrencyKey` pool and `total` caps across
everything, keys or not. The queue-level `concurrencyLimit` option keeps
working unchanged and is deprecated in favor of `concurrency`.
Enforcement happens server-side; servers without support accept the
option but do not enforce it yet.

Manage limits at runtime with the new `concurrencyLimits` namespace:
`list()` and `retrieve(name)` report each limit's bounds plus its live
`running` and `queued` counts, `override(name, { perKey, total })`
changes only the given bounds (overriding `total` to `0` pauses the
limit), and `reset(name)` restores the declared values.

Queue reads (`queues.list()` and `queues.retrieve()`) now report a
`version` that discriminates the shape: `V1` queues keep today's fields
(their own `concurrencyLimit` and its override state), while `V2` queues
(tasks declared with `concurrency`) carry no queue-level concurrency,
since their limits are read and overridden through `concurrencyLimits`
(a task's inline limit under its derived `task/<task-id>` name).
Existing reads keep compiling: a `V2` queue reports `concurrencyLimit`
as null and `concurrency` as undefined.

### Patch Changes

- Fix stale and empty project environment values in `trigger dev`, and
support empty values in `syncEnvVars()`.
([`f384e8334`](triggerdotdev@f384e83))
- Chat streams now report `Stream stalled: no records received` after
five retries of a connected stream that sends no records. Network
failures and browser wakeups retain automatic recovery. Healthy tool
calls with no records for about six minutes also reach this silence
limit. Watch subscriptions remain unlimited, and caller cancellation
still closes cleanly.
([triggerdotdev#4949](triggerdotdev#4949))
- Fixes warm starts silently failing for deployments built with 4.6.0 to
4.6.3 in projects that resolve `zod` to a 3.x release. The runner could
not parse the run handed to it by the warm-start service and exited,
leaving the run waiting until the platform redrove it a few minutes
later and started it cold. Redeploy to pick up the fix.
([triggerdotdev#4972](triggerdotdev#4972))
- Fix a ~6-second delay between a task finishing and its run completing
(and a ~31-second delay when cancelling a run) in projects that use zod
4.4 or newer. Run cost and billed usage was not impacted by this issue.
([triggerdotdev#4980](triggerdotdev#4980))
- Webhook verifier artifacts can now declare the provider's response
contract as data: a handshake `respondStatus`, the status codes returned
for accepted deliveries and rejected signatures, and a GET verification
flow (`getHandshake`) for providers that confirm a callback URL with a
challenge. HMAC verifiers can read the timestamp from a body field,
which the Linear provider config uses for its replay window, and the
dashboard's test-send re-signs a recorded sample as of now so it passes
that window.
([`5f54fb27f`](triggerdotdev@5f54fb2))
## @trigger.dev/react-hooks@4.7.0

### Minor Changes

- Control a task's concurrency with the new `concurrency` option, and
share limits across tasks with named concurrency limits. An inline shape
caps the task itself; `concurrencyLimit()` declares a limit any task can
hold (up to two named limits per task), and a trigger call can switch a
run's named limits with its own `concurrency` option.
([`ea9758117`](triggerdotdev@ea97581))

  ```ts
  import { concurrencyLimit, task } from "@trigger.dev/sdk";

export const openaiLimit = concurrencyLimit({ name: "openai", total: 25
});

  export const generateSummary = task({
    id: "generate-summary",
    concurrency: [{ perKey: 1, total: 5 }, openaiLimit],
    run: async (payload) => {},
  });
  ```

`perKey` caps each `concurrencyKey` pool and `total` caps across
everything, keys or not. The queue-level `concurrencyLimit` option keeps
working unchanged and is deprecated in favor of `concurrency`.
Enforcement happens server-side; servers without support accept the
option but do not enforce it yet.

Manage limits at runtime with the new `concurrencyLimits` namespace:
`list()` and `retrieve(name)` report each limit's bounds plus its live
`running` and `queued` counts, `override(name, { perKey, total })`
changes only the given bounds (overriding `total` to `0` pauses the
limit), and `reset(name)` restores the declared values.

Queue reads (`queues.list()` and `queues.retrieve()`) now report a
`version` that discriminates the shape: `V1` queues keep today's fields
(their own `concurrencyLimit` and its override state), while `V2` queues
(tasks declared with `concurrency`) carry no queue-level concurrency,
since their limits are read and overridden through `concurrencyLimits`
(a task's inline limit under its derived `task/<task-id>` name).
Existing reads keep compiling: a `V2` queue reports `concurrencyLimit`
as null and `concurrency` as undefined.

### Patch Changes

- Updated dependencies:
  - `@trigger.dev/core@4.7.0`
## @trigger.dev/sdk@4.7.0

### Minor Changes

- Chat agents can now scope concurrency per session. Pass
`concurrencyKey` (for example, your chat ID or tenant ID) and
trigger-time named limits via `triggerConfig.concurrency` when starting
a chat session, from `chat.createStartSessionAction`, the `AgentChat`
client, or a handover. Keys are never defaulted, so a session without
one shares the task's keyless pool.
([`ea9758117`](triggerdotdev@ea97581))

  ```ts
  const start = chat.createStartSessionAction("support-chat", {
    triggerConfig: { concurrencyKey: user.id },
  });
  ```

- Concurrency limits can now be paused and resumed, just like queues:
`concurrencyLimits.pause(name)` stops every run holding the limit from
being dequeued while keeping its configured bounds, and
`concurrencyLimits.resume(name)` starts them again.
([`fa94febb6`](triggerdotdev@fa94feb))

  ```ts
  import { concurrencyLimits } from "@trigger.dev/sdk";

  await concurrencyLimits.pause("openai");
  await concurrencyLimits.resume("openai");
  ```

- Control a task's concurrency with the new `concurrency` option, and
share limits across tasks with named concurrency limits. An inline shape
caps the task itself; `concurrencyLimit()` declares a limit any task can
hold (up to two named limits per task), and a trigger call can switch a
run's named limits with its own `concurrency` option.
([`ea9758117`](triggerdotdev@ea97581))

  ```ts
  import { concurrencyLimit, task } from "@trigger.dev/sdk";

export const openaiLimit = concurrencyLimit({ name: "openai", total: 25
});

  export const generateSummary = task({
    id: "generate-summary",
    concurrency: [{ perKey: 1, total: 5 }, openaiLimit],
    run: async (payload) => {},
  });
  ```

`perKey` caps each `concurrencyKey` pool and `total` caps across
everything, keys or not. The queue-level `concurrencyLimit` option keeps
working unchanged and is deprecated in favor of `concurrency`.
Enforcement happens server-side; servers without support accept the
option but do not enforce it yet.

Manage limits at runtime with the new `concurrencyLimits` namespace:
`list()` and `retrieve(name)` report each limit's bounds plus its live
`running` and `queued` counts, `override(name, { perKey, total })`
changes only the given bounds (overriding `total` to `0` pauses the
limit), and `reset(name)` restores the declared values.

Queue reads (`queues.list()` and `queues.retrieve()`) now report a
`version` that discriminates the shape: `V1` queues keep today's fields
(their own `concurrencyLimit` and its override state), while `V2` queues
(tasks declared with `concurrency`) carry no queue-level concurrency,
since their limits are read and overridden through `concurrencyLimits`
(a task's inline limit under its derived `task/<task-id>` name).
Existing reads keep compiling: a `V2` queue reports `concurrencyLimit`
as null and `concurrency` as undefined.

### Patch Changes

- Add an optional `onSettled` callback to
`TriggerChatTransport.sendAction()` so callers can confirm that their
action's input was processed, independently of whether the response
stream closes.
([triggerdotdev#4956](triggerdotdev#4956))
- Chat agents now return to a durable wait when a session wake does not
deliver a matching message. This prevents resumed runs from staying
active until their maximum duration and preserves the configured turn
timeout across repeated wakes.
([`e6ec2c4e8`](triggerdotdev@e6ec2c4))
- Deprecate `queues.overrideConcurrencyLimit` and
`queues.resetConcurrencyLimit`. These operate on the legacy model where
a queue carried its own concurrency limit; declare concurrency with the
task `concurrency` option and manage it with
`concurrencyLimits.override` and `concurrencyLimits.reset` instead.
([`414e5a268`](triggerdotdev@414e5a2))
- Chat streams now report `Stream stalled: no records received` after
five retries of a connected stream that sends no records. Network
failures and browser wakeups retain automatic recovery. Healthy tool
calls with no records for about six minutes also reach this silence
limit. Watch subscriptions remain unlimited, and caller cancellation
still closes cleanly.
([triggerdotdev#4949](triggerdotdev#4949))
- Steering messages now remain in context across agent steps and keep
their original position in saved conversations, including custom
response data written between steps.
([`5619acf26`](triggerdotdev@5619acf))
- Updated dependencies:
  - `@trigger.dev/core@4.7.0`
## @trigger.dev/build@4.7.0

### Patch Changes

- Updated dependencies:
  - `@trigger.dev/core@4.7.0`
## trigger.dev@4.7.0

### Patch Changes

- Fix stale and empty project environment values in `trigger dev`, and
support empty values in `syncEnvVars()`.
([`f384e8334`](triggerdotdev@f384e83))
- Set up a new Trigger.dev account from the CLI. Login can prefill an
email address, save the user's full name after authorization, and resume
authorization later, while `init` can create the first organization,
activate its Free plan, and create the first project before scaffolding
the app.
([`fb3b26d4f`](triggerdotdev@fb3b26d))
- Added a `submit_feedback` MCP tool so coding agents can report a
confusing tool error, a docs mismatch, or a missing capability without
the user having to file it by hand. Turn it off with `--skip-telemetry`
or `TRIGGER_TELEMETRY_DISABLED`; the tool is hidden while it is off.
([`9d38ff508`](triggerdotdev@9d38ff5))
- Authenticate `trigger promote` with environment API keys supplied
through `TRIGGER_ACCESS_TOKEN`. Environment API key commands now use the
saved profile API URL when no explicit override is provided.
([`562c9433a`](triggerdotdev@562c943))
- Fix Windows deploys failing at indexing with `Cannot find module` on a
percent-encoded path when the project directory contains spaces or
non-ASCII characters.
([`b32c1d157`](triggerdotdev@b32c1d1))
- Updated dependencies:
  - `@trigger.dev/schema-to-json@4.7.0`
  - `@trigger.dev/core@4.7.0`
  - `@trigger.dev/build@4.7.0`
## @trigger.dev/python@4.7.0

### Patch Changes

- Updated dependencies:
  - `@trigger.dev/sdk@4.7.0`
  - `@trigger.dev/core@4.7.0`
  - `@trigger.dev/build@4.7.0`
## @trigger.dev/redis-worker@4.7.0

### Patch Changes

- Updated dependencies:
  - `@trigger.dev/core@4.7.0`
## @trigger.dev/rsc@4.7.0

### Patch Changes

- Updated dependencies:
  - `@trigger.dev/core@4.7.0`
## @trigger.dev/schema-to-json@4.7.0

### Patch Changes

- Convert Zod 4 `z.date()` fields to date-time strings in JSON Schema
without weakening validation for other unsupported types. This prevents
MCP tool discovery from failing when a tool input schema contains a
date.
([`f8babdf9b`](triggerdotdev@f8babdf))
- Updated dependencies:
  - `@trigger.dev/core@4.7.0`

</details>

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants