trigger.dev v4.6.0

Upgrade

npx trigger.dev@latest update  # npm
pnpm dlx trigger.dev@latest update  # pnpm
yarn dlx trigger.dev@latest update  # yarn
bunx trigger.dev@latest update  # bun

Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.6.0

Release notes

Read the full release notes: https://trigger.dev/changelog/v4-6-0

What's changed

Breaking changes

• Minimum supported Zod version is now 3.25.56 released in June 2025. Trigger.dev now uses Zod 4 by default. Projects using Zod 3.25.56 or later 3.x releases remain supported. (#4039). Zod remains a runtime dependency of packages that execute schemas, so existing and new installations continue to receive it automatically. The matching peer dependency range allows package managers to reuse either a compatible Zod 3 or Zod 4 installation from your project.

• Reading a session's .in channel (GET /realtime/v1/sessions/{id}/in and /in/records) now requires a secret key. Public tokens, including read:sessions:{id}, get a 403; they can still read .out and append to .in.

Highlights

• A failed write to a realtime or chat session stream no longer crashes the process running it, and a dropped chat session output write is now logged instead of swallowed. (fb25c0149)

Improvements

• The playwright build extension now works with Playwright 1.58 and later. 1.58 changed the playwright install --dry-run output, which made deploy image builds fail while downloading the browsers. (#4881)

• Rename the dev error link to "Ask Trigger about this error" (f999516a0)

• Automatically archive up to three inactive development branches when creating a branch at the plan limit. Connected and recently active branches remain protected, and the CLI reports which branches were archived. (dd55fdb5b)

• When the build log stream cannot be opened or disconnects during a build server deploy, the CLI now explains that the deployment itself is unaffected and exits immediately with a non-zero code, since it can no longer confirm the outcome. Previously a disconnect printed the raw stream error and left the process hanging. (#4887)

• Build logs no longer include docker's registry login output, most notably the credential-storage warning on failed builds. (#4909)

• Reduce sensitive values in CLI and SDK diagnostics, secure files created by trigger env pull, and remove credentials from collected Git remote metadata. (ff05824c1)

• chat.agent persists a conversation through a TranscriptStorage: an adapter with load and save that the runtime drives after every turn, failed turn and history-changing action. The platform snapshot stays the default; bring your own to write the conversation to your database as it happens. Each save carries both the changes since the last one (so a row store writes only what changed, and an undo is one truncateAfter) and the whole transcript as it now stands (so a document store writes it as-is with no state of its own). (#4896)

  chat.agent({
  id: "my-chat",
  storage: myTranscriptStorage,
  run: async ({ messages, signal, streamText }) =>
    streamText({ model, messages, abortSignal: signal }),
  });

  chat.createLoadTranscriptAction(storage) and useLoadTranscript read the conversation back the same way for every storage, and runTranscriptStorageTests from @trigger.dev/sdk/ai/test checks an implementation against the contract.

  Compaction summaries and chat.inject context now survive a continuation run, and crash recovery runs for every agent, including one that owns its own context. hydrateMessages is deprecated in favour of loadContext on a storage. The snapshot format is now version 2, which older SDK versions cannot read.

• chat.agent: a run that recovers a session with more than one in-flight user message no longer drops the unanswered ones if it restarts mid-recovery. Recovered messages now hold the resume cursor until each has been answered, so a restart re-answers the rest instead of resuming past them. Previously the cursor could advance past messages that were only held in memory, so a crash before they were dispatched lost them. (#4907)

• End a chat conversation from inside the agent with chat.close({ reason }). The session row is closed, further sends are refused with HTTP 409, and the run exits without scheduling a continuation, so a budget cap, a completed goal, or a signed-out user can stop the conversation rather than only the current run. (0a23814a0)

  chat.agent({
  id: "budgeted-agent",
  run: async ({ messages, signal }) =>
    streamText({ model: openai("gpt-4o"), messages, abortSignal: signal }),
  onBeforeTurnComplete: async ({ chatId }) => {
    if (await overBudget(chatId)) {
      chat.close({ reason: "Monthly budget reached" });
    }
  },
  });

  The current turn still streams in full. Decide the close before the turn ends (run(), prepareStep, onBeforeTurnComplete) so the closed state rides out on that turn's final record and the user sees it as soon as the answer finishes. TriggerChatTransport picks the close up from the response stream or from a refused send, exposes it as transport.sessionStatus(chatId) plus transport.sessionClosedReason(chatId), and stops sending and reconnecting. Closing a session from outside with sessions.close() now also reaches a live run, so an idle or suspended agent exits on its next wake instead of waiting out its idle timeout. Writes to a closed session's named side channels are refused with the same 409.

• Reading a page of a chat agent's conversation no longer downloads the whole conversation. The saved transcript now carries an index, so asking for the most recent messages fetches only those messages, and history loads in roughly constant time however long the chat gets. (b7e86f2af)

  A paged read also returns only the conversation itself. The model-side context an agent keeps, its compacted history and any injected context, is no longer included, so it cannot reach a browser through a load-transcript server action.

  The built-in storage is deliberately basic about long conversations: once an agent has compacted, it keeps roughly the last hundred messages and drops the rest, so what it rewrites each turn stops growing. A conversation that never compacts is kept whole. If your app renders history further back than that, give the agent your own transcript storage.

  The saved format has changed and an older SDK cannot read it, so a deployment rolled back to an earlier version will not find a readable transcript for conversations the newer version already saved, and those conversations continue from the live stream tail instead. Roll forward rather than back, or keep your own transcript storage.

• Adds the GetDeploymentArtifactUrlResponseBody schema for the deployment artifact download URL endpoint. (1a5ad1e5f)

• Deployments now return the --external-id they were deployed under as externalId, and a run can read its own from ctx.deployment.externalId. Also fixes the deployments list failing when one deployment had no git metadata. (879e8975b)

• Add an optional appliedSchedulePolicy field to the schedule API response. It is present only when a non-overridable plan policy applies a minimum window to a schedule (e.g. a free-plan schedule's minimum run interval); the configured window continues to be returned separately and unchanged. (2991bb48a)

• Triggering a task whose id cannot be represented in a URL (for example an id containing an unpaired surrogate) now fails with a clear error naming the task id, instead of a cryptic URI error. (ad821eaea)

• Actions can now become turns. onAction edits history with chat.history; to answer after the edit, return chat.turn() and a turn runs on the edited history with everything a turn has: the agent's system prompt and tools, steering, compaction, injected instructions, onTurnStart and onTurnComplete, and persistence. A regenerate is chat.history.slice(0, -1); return chat.turn();. (#4816)

  onAction: async ({ action }) => {
  if (action.type === "regenerate") {
    chat.history.slice(0, -1);
    return chat.turn();
  }
  if (action.type === "undo") chat.history.slice(0, -2); // edit only
  },

  Returning a StreamTextResult, string or UIMessage from onAction is no longer supported and now fails with an error pointing to ...

trigger.dev v4.5.16

Upgrade

npx trigger.dev@latest update  # npm
pnpm dlx trigger.dev@latest update  # pnpm
yarn dlx trigger.dev@latest update  # yarn
bunx trigger.dev@latest update  # bun

Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.16

Release notes

Read the full release notes: https://trigger.dev/changelog/v4-5-16

What's changed

Improvements

• The trigger.dev deploy and trigger.dev dev commands now warn (with the suggested fix) when your code loads a package through createRequire() that won't be available in the deployed image. Previously it would fail at runtime in production to load the package. Deploys also now show bundler warnings for your code instead of discarding them. (#4851)

Bug fixes

• Fixes an issue introduced in 4.5.11 that made deploy image builds of projects with large dependency trees noticeably slower. (#4878)

Server changes

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

• A durable guard improves reliability for runs waiting on triggerAndWait or batchTriggerAndWait if there's a database error that interrupts a child run finishing. (#4849)

All packages: v4.5.16

@trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev

Contributors

Chris Arderne, @d-cs, Matt Aitken, Saadi Myftija, github-actions[bot], James Ritchie

Full changelog: v4.5.15...v4.5.16

trigger.dev v4.5.15

Upgrade

npx trigger.dev@latest update  # npm
pnpm dlx trigger.dev@latest update  # pnpm
yarn dlx trigger.dev@latest update  # yarn
bunx trigger.dev@latest update  # bun

Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.15

Release notes

Read the full release notes: https://trigger.dev/changelog/v4-5-15

What's changed

Improvements

• Stop shipping compiled test files in the published packages. The *.test.ts sources were being emitted into dist, adding dead weight to every install and leaving modules that require("vitest") (not a dependency) inside the tarball, which tripped tooling that walks every file in a package. (#4833)

• Named side channels on a Session: durable, two-way realtime streams that outlive a single run and are shared across runs. Open a channel with sessions.open(id).channel(name) (or chat.channel(name) inside a chat.agent) to get an .in/.out pair addressed by name rather than the reserved default pair. Writing a side channel's .in does not wake or trigger a run, so a channel can carry out-of-band data (a stream of frames, a control signal) that many clients read while the agent produces it. (#4815)

  // Inside a chat.agent: stream frames on a named channel, wakes nothing
  const frames = chat.channel("screenshots");
  await frames.out.append(frame);
  frames.in.on((control) => {
  /* client control, no suspend */
  });

  Declare channel record types once with sessions.defineChannel(...) and infer them on both the producer and the consumer, including useSessionStreamChannel in React. Channels get a default retention that keeps them bounded, overridable per channel.

• Session triggerConfig.tags now accepts up to 10 tags, matching the run tag limit. Previously it was capped at 5, which for chat.agent left room for only 4 of your own tags after the automatic chat:{chatId} tag. (#4832)

All packages: v4.5.15

@trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev

Contributors

Matt Aitken, github-actions[bot], Saadi Myftija, claude[bot], Eric Allam, James Ritchie

Full changelog: v4.5.14...v4.5.15

Installation

helm upgrade --install trigger \
  oci://ghcr.io/triggerdotdev/charts/trigger \
  --version "4.5.15"

Changes

See commit history for detailed changes in this release.

trigger.dev v4.5.14

Upgrade

npx trigger.dev@latest update  # npm
pnpm dlx trigger.dev@latest update  # pnpm
yarn dlx trigger.dev@latest update  # yarn
bunx trigger.dev@latest update  # bun

Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.14

Release notes

Read the full release notes: https://trigger.dev/changelog/v4-5-14

What's changed

Improvements

• Native build server deploys now show a single updating build log line by default; pass --build-logs full to stream every line (always used in CI and when output is not a terminal). (#4817)

• Realtime stream subscriptions can now refresh an expired access token and reconnect, via a new optional refreshAccessToken option on the client configuration and the React hooks. (#4811)

• Subscribe to a realtime stream from its latest record instead of replaying the whole history. Pass from: "latest" to useRealtimeStream, streams.read(), or fetchStream to start at the current tail (the latest record, then live updates) instead of replaying (a live "last value" view), and maxParts to keep the accumulated parts array bounded. A reconnect or remount resumes from the last record it saw, so no records are missed and none are replayed. from: "latest" needs a server that supports it; older servers safely fall back to a full replay. (#4811)

  useRealtimeStream also gains a lastEventId option and returns the lastEventId of the last part seen, so you can persist the cursor (for example across a page reload) and resume exactly where you left off. An onParts callback delivers each throttled batch of parts with their event ids.

  const { parts, lastEventId } = useRealtimeStream<Frame>(runId, "frames", {
  from: "latest", // skip history, start at the current tail
  maxParts: 1, // keep only the most recent frame
  lastEventId: savedCursor, // resume from a persisted cursor
  onParts: (batch) => save(batch.at(-1)?.id), // track the cursor
  accessToken,
  });

• Added a useSessionStream React hook for reading a session's output or input channel in realtime. It accumulates records with automatic resume from the last record you received, and supports from: "latest" (start at the current tail, only new records after you connect), maxRecords (keep a bounded number of records in memory), a lastEventId resume cursor, and an onRecords callback that delivers each throttled batch of records with their event ids. (#4811)

Server changes

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

• Task retries that wait in the queue no longer count against the queue's internal redelivery limit, so runs with many long-delay retries are not wrongly failed with TASK_RUN_DEQUEUED_MAX_RETRIES. (#4810)

All packages: v4.5.14

@trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev

Contributors

Saadi Myftija, James Ritchie, @d-cs, github-actions[bot], Matt Aitken, @nicktrn, Chris Arderne, Eric Allam

Full changelog: v4.5.13...v4.5.14

Upgrade

npx trigger.dev@latest update  # npm
pnpm dlx trigger.dev@latest update  # pnpm
yarn dlx trigger.dev@latest update  # yarn
bunx trigger.dev@latest update  # bun

Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.13

Release notes

Read the full release notes: https://trigger.dev/changelog/v4-5-13

What's changed

Improvements

• trigger.dev deploy now asks the server whether to build with Depot or the native build server unless --native-build, --depot-build, or --local-build is passed, so the native build server can be rolled out per organization without a CLI change. --local-bundle and --detach now require --native-build. (#4803)

• Add an experimental --local-bundle deploy flag that runs the install and bundling steps on your machine and uploads only the build output; the image is still built remotely. Useful when your project's install step needs tooling or credentials that only exist locally. (#4331)

• Send the CLI version header on all API requests so deployments are attributable to a CLI version (#4778)

• A message that arrives mid-turn and is not injected into that turn is now answered as the next turn, instead of being dropped. This is what the pendingMessages docs have always described, and it applies to the default too: configuring pendingMessages without a shouldInject declines every batch, which previously meant every mid-turn message was lost with no error at either end. (#4795)

  chat.agent({
  id: "my-chat",
  pendingMessages: {
    onReceived: ({ message }) =>
      logger.info("arrived mid-turn", { id: message.id }),
    // Only interrupt once the agent has started calling tools.
    shouldInject: ({ steps }) => steps.length > 0,
  },
  run: async ({ messages, signal }) =>
    streamText({
      model,
      messages,
      abortSignal: signal,
      // Required for injection. Without it nothing injects, and every
      // mid-turn message is answered as the next turn instead.
      ...chat.toStreamTextOptions(),
    }),
  });

  A declined message keeps its place in the queue, so it survives a crash and is answered by whichever run picks the conversation up. An injected one is consumed at the moment it is injected, so it is never also answered as a later turn.

• Browser chats now keep the active turn open across page reloads when older completion records are replayed. (#4643)

• Add chat.endAndContinue() so fully hand-rolled custom chat agents can hand a conversation off to a fresh run on the latest deployed task version while preserving unconsumed Session input. (#4647)

• Custom chat agents now validate and parse client data declared with chat.withClientData({ schema }) before passing it to agent code. (#4646)

Bug fixes

• Fixes a case where a chat could silently lose a message. If a message arrived while the agent was between turns and a stop arrived after it, the cursor the next boot resumed from could point past that message, so it was never answered and no error was raised. This affected chat.agent, not just custom agents. (#4644)

  Fixes a recovered answer being cut off. After a crash the agent replays the message it had not answered yet, but it was replaying the stop that arrived after that message too, so the turn answering it was aborted the moment it began. A stop is now only applied to the turn that was live when it arrived. That holds however the stop got there: sent after the last completed turn, or sent to a chat whose most recent turn was completed by an older version of the SDK.

  One limitation to know about: the recovered answer is persisted correctly, but a chat page that stayed open across the crash keeps showing the partial answer it had already received. Reload the page to see the full recovered answer.

  Also fixes a retried send being answered twice. When a send was retried and its idempotency claim was lost, the agent could consume the same message a second time.

  Custom agent loops can now inspect pending chat input without consuming it, and consume one record at a time, with chat.messages.hasPending() and chat.messages.next(). Records carry stable identifiers so a redelivery is recognisable.

  if (await chat.messages.hasPending()) {
  const record = await chat.messages.next({ timeoutInSeconds: 0 });
  if (record) handle(record.payload);
  }

  hasPending() answers for messages alone, so a message sitting behind a stop, or behind a record this version of the SDK does not recognise, still reports as pending and is still delivered. Anything the agent has no consumer for is discarded rather than left where it would make every message queued behind it undeliverable. chat.messages.next() returning undefined means no message became consumable before the timeout.

  chat.writeTurnComplete()'s sessionInEventId is the cursor that is safe to resume from, not the sequence of the record the turn answered. It is held back behind any message still waiting to be handled, so a value below the record you just handled is expected.

• Fixed a chat agent hanging after an interrupted turn: when a run was killed mid-answer (out of memory, crash, or eviction) and only the one message it was answering was still outstanding, the new run never replied to it. That message is now re-answered on the new run. (#4768)

• Fix chat transport discarding the next turn after stopping generation. skipToTurnComplete is now reset when a new message or action is sent, so a message sent after stopGeneration streams normally instead of leaving the chat stuck in a streaming state. (#4744)

• Fixes a message sent while the agent was mid-answer being lost if the run then crashed. The cursor written at the end of each turn could point past a message that had arrived during that turn but had not been answered yet, so the next boot skipped it and no error was raised anywhere. Such a message is now held until a turn actually takes it. (#4795)

  This also removes the in-memory buffer those messages used to sit in, on both chat.agent and chat.createSession(), so a message waiting for its turn is durable rather than only present in the worker that received it.

Server changes

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

• Self-hosted instances can now disable the admin dashboard and user impersonation entirely. See the self-hosting docs for the new setting. (#4774)
• The dashboard has two new themes, Black and White, plus appearance options for stronger colors and underlined links. (#4547)
• Deployment logs no longer jump to the bottom while you are reading earlier output. Scroll up to pause auto-scroll, and scroll back down or use the new scroll-to-bottom button in the log header to resume following. (#4776)
• Customize the runs list: show, hide, and reorder columns, and add smart columns that pull a value straight out of a run's payload, metadata, or output. Your column choices are saved in the page URL, so you can share a view, bookmark it, or save it straight to your favorites. (#4652)
• Stop the browser offering to autofill or save environment variable values as saved credentials. (#4777)
• Cut webapp CPU usage by about a quarter on the routes that workers call most, freeing headroom at the same request rate. Detailed event-loop blocking traces are no longer recorded by default, because producing them was itself a large part of that cost. (#4746)
• When a runs list or runs.list API request spans too much data to complete, it now returns a clear, actionable error asking you to narrow the time range, instead of failing with a generic error. (#4773)
• Improved the performance and reliability of the runs list and the runs.list API, especially for large projects and filtered views. (#4763)
• New Vercel connections now get version skew protection turned on automatically, so each run uses the task version its deployment shipped with. Automatic atomic deployments are deprecated and no longer offered when you connect a project, but stay available in your Vercel integration settings. (#4741)
• The Staging branch setting now shows an upgrade prompt on plans that don't include a Staging environment, instead of looking editable and then silently doing nothing when saved. (#4784)

All packages: v4.5.13

@trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev

Contributors

@d-cs, Eric Allam, Saadi Myftija, Graham Trempe...

Installation

helm upgrade --install trigger \
  oci://ghcr.io/triggerdotdev/charts/trigger \
  --version "4.5.14"

Changes

See commit history for detailed changes in this release.

Installation

helm upgrade --install trigger \
  oci://ghcr.io/triggerdotdev/charts/trigger \
  --version "4.5.13"

Changes

See commit history for detailed changes in this release.

trigger.dev v4.5.12

Upgrade

npx trigger.dev@latest update  # npm
pnpm dlx trigger.dev@latest update  # pnpm
yarn dlx trigger.dev@latest update  # yarn
bunx trigger.dev@latest update  # bun

Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.12

Release notes

Read the full release notes: https://trigger.dev/changelog/v4-5-12

What's changed

Highlights

• Define stable execution windows on declarative scheduled tasks. Schedule API responses now expose both the nominal CRON time and its assigned time, while the dashboard shows configured windows and upcoming assignments. (#4572)

Improvements

• trigger.dev deploy --external-id tags a deployment with an id of your own — a commit SHA, a CI run id, a release tag — so runs triggered by that release of your app go to that deployment. Deploying an id that is already deployed builds nothing and reports the existing version instead of creating a duplicate; use --force to rebuild it. (#4663)
• List the current Production runtime for every accessible project with trigger projects list. Add --needs-update to identify projects currently running Node.js 21. (#4659)
• New projects created with trigger init use Node.js 24 by default. Deployments without explicit runtime now use their project's configured default runtime. (#4649)
• Deployment builds now use custom base layer images and no longer install system packages during every build. This improves layer caching resulting in both faster deployments and faster image pulls on the worker cluster side. (#4602)
• Unrelated runs are no longer merged into a single trace in your external observability tool when they happen to execute on the same warm worker process. (#4534)
• Task metrics no longer go missing for projects that configure their own metricExporters or metricReaders, and the flush error that came with it is gone. (#4613)
• idempotencyKeys.reset() now works when your idempotency key is itself 64 characters long (for example if you use a hash of your own as the key). Previously any 64-character key was assumed to be already hashed, so passing one along with a scope silently ignored the scope and the reset never found a matching run. Keys returned by idempotencyKeys.create() continue to be reset exactly as before. (#4626)
• Pin runs to the deployment your calling code came from, so an old release never triggers tasks from a new one: set TRIGGER_EXTERNAL_DEPLOYMENT_ID to the id you deployed with, or TRIGGER_AUTOMATIC_SKEW_VERSION_PROTECTION=1 to detect the commit automatically on Vercel and most CI systems. Runs triggered before that deployment finishes building wait for it, then start pinned. (#4664)
• Fair queue tenants can no longer get permanently stuck behind leaked concurrency slots. Slots are now freed on every path that finishes a message, a failed release no longer causes a message to run twice or lose its retry, and a background sweep frees any slot that does leak, so a tenant's queues recover on their own instead of needing manual cleanup. (#4540)

Server changes

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

• Deployments and runs now show the external ID they were deployed or pinned with, so you can trace a run back to the release of your app that triggered it. (#4665)
• Operators can now route an organization's runs to specific Kubernetes node pools. (#4655)
• Dashboard pages load faster on projects with many preview branches by no longer loading every environment on each page. (#4606)
• Global log search now supports faster bounded substring matching and clearer time-range expansion. (#4615)
• Triggering tasks is now more resilient to brief, transient service interruptions, so short stalls are less likely to surface as errors. (#4623)
• Failed AI SDK tool call and embedding spans now show the error message and stack trace in the run inspector, below the tool input. (#4653)
• Archiving a branch now returns you to the same page of the branches list, keeping your place, search and filters instead of resetting to the first page. (#4724)
• Using * as a concurrency key no longer stops a queue from being processed. Triggering a single run with that key could leave the whole queue stalled, including runs using other concurrency keys on it, until something else was triggered on the same queue. (#4628)
• Fixed a brief window after promoting or rolling back a deployment where newly triggered runs could still execute on the previous version. New runs now pick up the current version immediately. (#4622)
• Root API keys no longer show an environment creation timestamp as their creation date. (#4612)
• The app version shown on the organization settings page now reports the real version instead of v0.0.0. (#4611)
• Fix paused environments starting to run work again after a deploy: a paused environment now stays paused until you resume it. (#4625)
• Reject alert webhook destinations in reserved benchmarking IP ranges. (#4735)
• TRQL queries using the PREWHERE clause are now rejected with a clear error message. Use WHERE instead, which is filtered the same way but keeps your data isolation guarantees intact. (#4735)
• Run trace rows now respond consistently to mouse and keyboard selection, including Alt-click expansion controls. (#4701)
• The "Back to app" button in organization settings now returns you to that organization instead of your most recently used one. (#4632)
• Runs triggered with a ttl could get permanently stuck in the queued state if they started executing and were then requeued after a failure (for example a worker dying mid-run) once the TTL had already elapsed. Requeued runs now dequeue normally: a run's TTL only applies while it is waiting to start for the first time. (#4669)

All packages: v4.5.12

@trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev

Contributors

Chris Arderne, @nicktrn, Eric Allam, Oskar Otwinowski, claude[bot], Matt Aitken, Saadi Myftija, github-actions[bot], @NERLOE, Katia Bulatova, Wes Mason

Full changelog: v4.5.11...v4.5.12

Installation

helm upgrade --install trigger \
  oci://ghcr.io/triggerdotdev/charts/trigger \
  --version "4.5.12"

Changes

See commit history for detailed changes in this release.