chore: release v4.5.13 by github-actions[bot] · Pull Request #4769 · triggerdotdev/trigger.dev

github-actions · 2026-08-25T07:53:10Z

Summary

4 new features, 7 improvements, 3 bug fixes.

Improvements

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)

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

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)

Raw changeset output

Releases

@trigger.dev/build@4.5.13

Patch Changes

Updated dependencies:
- @trigger.dev/core@4.5.13

trigger.dev@4.5.13

Patch Changes

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)
Updated dependencies:
- @trigger.dev/core@4.5.13
- @trigger.dev/build@4.5.13
- @trigger.dev/schema-to-json@4.5.13

@trigger.dev/core@4.5.13

Patch Changes

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

@trigger.dev/python@4.5.13

Patch Changes

Updated dependencies:
- @trigger.dev/sdk@4.5.13
- @trigger.dev/core@4.5.13
- @trigger.dev/build@4.5.13

@trigger.dev/react-hooks@4.5.13

Patch Changes

Updated dependencies:
- @trigger.dev/core@4.5.13

@trigger.dev/redis-worker@4.5.13

Patch Changes

Updated dependencies:
- @trigger.dev/core@4.5.13

@trigger.dev/rsc@4.5.13

Patch Changes

Updated dependencies:
- @trigger.dev/core@4.5.13

@trigger.dev/schema-to-json@4.5.13

Patch Changes

Updated dependencies:
- @trigger.dev/core@4.5.13

@trigger.dev/sdk@4.5.13

Patch Changes

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 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.
Updated dependencies:
- @trigger.dev/core@4.5.13

devin-ai-integration