Helm Chart 4.5.15

Installation

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

Changes

See commit history for detailed changes in this release.

trigger.dev v4.5.14

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

trigger.dev v4.5.13

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...

Helm Chart 4.5.14

Installation

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

Changes

See commit history for detailed changes in this release.

Helm Chart 4.5.13

Installation

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

Changes

See commit history for detailed changes in this release.

trigger.dev v4.5.12

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

Helm Chart 4.5.12

Installation

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

Changes

See commit history for detailed changes in this release.

trigger.dev v4.5.11

trigger.dev v4.5.11

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.11

Release notes

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

What's changed

Highlights

• Allow trigger deploy to authenticate with an environment API key from TRIGGER_ACCESS_TOKEN. (#4561)

Improvements

• Chat in the browser now reconnects when the connection drops mid-turn, instead of leaving the reply stuck as if it were still generating. Reports can be fetched as structured data with the json format, and the shortest report period is now one minute (1m, 30m, 1h, 7d). The mint-token command's help is clearer too: a token minted without --cap is read-only, and --ttl shows the correct maximum lifetime of 7 days. (#4418)

• The dev environment onboarding now tracks real progress. After you run init, the setup checklist marks your project as initialized, and it updates live as your dev server connects and your tasks register. The blank state also adds a "Copy AI agent prompt" button that copies a ready-to-paste setup prompt (pre-filled with your project reference) for Claude Code, Cursor, or any coding agent. (#4563)

  The init scaffold now imports from @trigger.dev/sdk instead of the deprecated @trigger.dev/sdk/v3 subpath.

• Deployed images now ship dependencies and bundled task code as separate layers. Repeat deploys with unchanged dependencies typically push and pull far less data, making deploys and worker image pulls faster. (#4551)

• The current-worker API now reports each task's queue, so you can see which tasks write to a given queue. (#4525)

• Watch-mode chat streams now survive quiet windows and page reloads, and a reply cut off by a lost connection shows an error instead of appearing finished. Aborting a resumed subscription only closes your local stream — call stopGeneration(chatId) or pass stopOnAbort: true to stop the run. Also fixed a race where quickly restarting a stream could break stop and reconnect, and stopping a chat now hands it back to your other tabs instead of leaving them read-only. (#4516)

Server changes

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

• The dashboard agent now has a monthly message allowance and plan-based limits on watches. Queries stay read-only with clearer errors when busy, and messages with unusual characters no longer fail to send. (#4516)

• Meet the dashboard agent: a chat in every environment that answers questions about your runs, queues, errors and health with real data and links, replacing Ask AI everywhere it used to appear. Investigate a failed run, an error, a backed-up queue or a run that hasn't started to get a worked-through answer — what happened, why, and how to fix it, with every claim linked to the runs, errors and deploys behind it. It reads your data read-only, works on preview and dev branches with that branch's own data, and reads the same everywhere — dashboard, terminal, editor. A very long chat keeps working: the agent summarises the earlier part and carries on.

  Watch… on a run, queue, error or the health report tells you when things change: a run finishes, a queue clears or grows past a number you pick, an error comes back, an environment recovers. The answer arrives in the chat and, if you want, by email, Slack or webhook — and the agent can look into bad news on its own. A watch reaches you on any browser you sign in from, without opening the chat first.

  A sample of conversations is scored automatically so the agent keeps getting better; only the score and a one-line summary are kept, never your messages, data or code, and we can switch it off for your organization on request. Ask the agent instead of the Docs buttons in page headers — they stay there when the agent isn't available to you. Separately, a queue's wait times, peak depth, throughput and throttling can now be read from the API. (#4418)

• Add backend support for delaying cron schedules within a specified window with a minimum of 60 seconds. (#4566)

• Reduced recurring background database load from the billing-limit recovery check, so paused environments are reconciled with less overhead. (#4590)

• Validating a schedule when deploying or updating a schedule now does less work on projects with many preview branches, so those operations stay fast as branches accumulate. (#4598)

• Project pages now load faster for projects with a large number of preview branches, by no longer loading archived branch environments that aren't shown. (#4595)

• Database queries that filter on a list of values now reuse cached query plans more consistently, instead of forcing the database to re-plan whenever the list length changes. (#4480)

• Routine cleanup of old dashboard agent data now runs on its own schedule. (#4599)

• Database connection metrics are now reported for every configured database connection instead of only the primary one, and stay accurate regardless of connection type. (#4541)

• Deployment-related API endpoints now draw from their own generous rate limit budget, configurable via the DEPLOYMENT_RATE_LIMIT_* environment variables, so runtime API traffic no longer competes with deployments for the same per-environment budget. (#4565)

• Deleting or editing a secret environment variable is now fast and no longer slows down as a project accumulates variables. (#4555)

• Speed up personal access token lookups by indexing them on their owner (#4588)

• Switching project or organization in the sidebar now keeps you on the same page instead of sending you back to Tasks. Pages for a specific run, deploy or other single item open the matching list instead. (#4585)

• Reduced database load when loading the dashboard by removing an unused organization member count that was being calculated on every page navigation. (#4587)

• The environment variables page now loads a page at a time, keeping it fast for projects with a large number of variables. Search matches variable names across every page. (#4597)

• Groundwork for an alternative database connection driver, gated behind configuration and disabled by default, so there is no change to default behavior. (#4539)

• Deleting an alert channel is now fast and no longer slows down as a project builds up alert history. (#4554)

• Reduced internal overhead on the API under high load. (#4532)

• Out-of-date upgrade prompts no longer appear in the dashboard: the "V4" badges and the notices saying preview branches and the queues table need V4 have been removed. The side menu still warns you when a project is on v3, with updated wording and a link to the v4 upgrade guide. (#4589)

• Make background worker registration cheaper for projects with many scheduled tasks by scoping declarative schedule reconciliation to the current environment and dropping redundant schedule lookups. (#4577)

• Speed up setting and importing environment variables for projects with many variables. (#4579)

• Loading the deployments list is now faster, especially when filtering by deployment status on projects with many deployments. (#4591)

• Fixed the billing limits page timing out for organizations with many preview branches, especially while a spend limit was being enforced. The page now loads quickly, so you can raise or resolve your limit without delay. (#4594)

• Fix the Concurrency page showing the plan's default concurrency for the dev environment instead of the environment's actual limit. (#4596)

• Creating an organization sometimes left you back on the creation form even though the organization had already been created, so clicking Create again made a duplicate. Creating an organization now completes and takes you to your new organization. (#4530)

• Ensure creating a project completes instead of returning to its creation form after a navigation error. (#4584)

• Renaming a pro...

Helm Chart 4.5.11

Installation

helm upgrade --install trigger \
  oci:https://github.com/proxy/ghcr.io/triggerdotdev/charts/trigger \
  --version "4.5.11"

Changes

See commit history for detailed changes in this release.

trigger.dev v4.5.10

trigger.dev v4.5.10

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.10

Release notes

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

What's changed

Highlights

• Allow task-scoped environment API keys to run batch operations for their permitted tasks. The SDK declares the batch's task set before creation, and @trigger.dev/core/v3/apiKeys now exports the additional-key format helper. (#4389)

Improvements

• Refresh package builds for TypeScript 7 compatibility while preserving existing runtime entry points. Projects using emitDecoratorMetadata() with TypeScript 7 can install the @typescript/typescript6 compatibility package alongside it; the package remains optional, so installing the Trigger.dev CLI does not install an additional compiler. (#4318)

• AgentChat.reconnect() now settles promptly when reconnecting to an idle chat instead of holding the connection open for the full long-poll window. Also upgrades the S2 streamstore client to 0.25 and moves realtime streams to S2's current hosts. (#4349)

• You can now choose the region a run executes in when triggering a task through the MCP server. (#4439)

• Transient connection errors when a run starts are now retried for longer, so a brief connectivity blip no longer sends the run back through the queue and delays its first attempt. (#4441)

• debounce now works when you pass an array of items to batchTrigger or batchTriggerAndWait, and when you trigger from useTaskTrigger. Previously the option was accepted by the types and dropped before the request was sent, so every trigger created its own run instead of collapsing onto the debounce key. (#4520)

  await myTask.batchTrigger([
  {
    payload: { id: "a" },
    options: { debounce: { key: "same-key", delay: "30s" } },
  },
  {
    payload: { id: "b" },
    options: { debounce: { key: "same-key", delay: "30s" } },
  },
  ]);

  The streaming (async iterable) forms of the batch calls were already forwarding debounce correctly.

Bug fixes

• Fix a chunk occasionally dropped when a chat.agent run takes over from the warm first turn. The realtime stream writer now reports the inclusive last-written position as the resume cursor, so the agent's first record after the handover is no longer skipped. (#4349)
• Fix a preloaded chat.agent run dropping an in-flight message when it retries after an out-of-memory error. The message being processed when the run hit the OOM is now recovered and re-run on the retry, instead of being skipped while the run waited for a new message. (#4349)

Server changes

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

• Self-hosted deployments can now create multiple full-access API keys for each environment. (#4390)
• Short links like /_/apikeys now take you straight to that page in your current project and environment, so you no longer need the full URL with your org, project and environment in it. (#4523)
• The dashboard gets a refreshed Dark theme as its new default look. On the account page you can switch to Light, System preference (follows your OS), or the original Classic look, and fine-tune the new themes with a contrast slider. (#4206)
• Additional environment API keys can now create scoped public access tokens. (#4390)
• Additional environment API keys can authenticate API requests using their configured permissions, with revoked and expired keys rejected. Batch responses use server-issued public access tokens so additional keys never need the environment signing secret. (#4389)
• Self-hosted Kubernetes deployments can now add tolerations to run pods, so runs are allowed onto tainted nodes. An invalid toleration now stops the supervisor at startup instead of failing every run pod, so check existing values before upgrading. (#4491)
• Lower background database load during deployments and dev sessions for projects that use declarative schedules. (#4522)
• Triggering a task now does one fewer database write, so runs reach the queue slightly faster. (#4419)
• Creating or updating a schedule, and deploying a project with declarative schedules, is faster in long-lived projects with many deploys. (#4518)
• Admins opening an impersonation link from outside the dashboard now get a confirmation page naming the organization and destination instead of being bounced back, and while impersonating they can switch to "View as user" to see the dashboard exactly as that user sees it, with the admin-only UI and the impersonation highlight both hidden. Stopping impersonation is still one click away in the account menu. (#4421)
• Browser tabs now name the page you're on, and the run, task or queue when you're looking at one, instead of all reading "Trigger.dev". (#4517)
• Allow the database connection pool and connect timeouts to be tuned separately for each database's writer and read replica, falling back to the shared defaults when unset. (#4515)
• In-app feedback and add-on/quota requests are now recorded with more account context for the support team. (#4368)
• Self-hosted Kubernetes deployments now measure running-task count more accurately when deciding whether to pause pulling new work, so the safeguard engages closer to its configured thresholds. (#4442)
• The Queues pages now open on the last hour instead of the last day, and remember the time period you picked when you navigate between queues or reload the page. (#4438)
• Speeds up resolving the latest worker version and deployment for an environment, removing an occasional stall when triggering runs in projects that have accumulated many deployed versions. (#4452)
• API rate limits now apply per environment, so creating extra API keys no longer increases how many requests an environment can make. (#4508)
• When the capacity signal drops out, the last decision is held for a grace period rather than released. (#4444)
• Batch triggers no longer fail to start their runs when an environment is under heavy API load. If a batch still can't finish being created, batchTriggerAndWait now fails with an error instead of leaving the parent run waiting forever, and the batches page says so rather than reporting that it resumed. (#4397)
• Triggering a run with a very large priority no longer fails. The priority is now capped to the highest supported value instead of erroring out. (#4512)
• Fix debounce doing nothing when the delay was longer than an hour, which made every trigger
  create its own run instead of collapsing onto the debounce key. Debounced runs now keep being
  pushed back for as long as triggers keep arriving, so set maxDelay when the work has to happen
  eventually, and settings that could never debounce are rejected rather than silently ignored. (#4521)
• Honor the configured database connection timeout so brief connection spikes no longer surface as spurious "can't reach database server" errors. (#4513)
• Fixed a rare case where a single run or span carrying data that could not be ingested would make other runs or trace events in the same batch go missing from the runs list, traces, and logs. Now the rest of the batch is always kept: an affected run still appears with its status (only its un-ingestable output is dropped), and an affected trace event or payload is skipped instead of taking down everything around it. (#4358)
• Fix the sidebar "Help & Feedback → Contact us" form sometimes not sending your message. It now sends reliably every time. (#4445)
• Requests spanning multiple tasks now require permission for every requested task instead of accepting permission for only one task. (#4389)
• The four charts at the top of the Queues page now always cover the whole environment, so paging through or re-sorting your queues no longer changes them. The schedul...