## Summary
2 new features, 9 improvements, 3 bug fixes.
## Highlights
- Allow additional environment API keys to create scoped public access
tokens through the Trigger.dev API. Use server-issued public access
tokens for batch operations so environment-scoped API keys can read
batch results.
([#4387](#4387))
## Improvements
- Preserve the partial assistant message when a chat turn's model stream
fails mid-response. `chat.agent` now passes the recovered partial to
`onTurnComplete`, and `chat.createSession`'s `turn.complete()` keeps it
before rethrowing, instead of dropping the streamed-so-far output.
([#4348](#4348))
## Server changes
These changes affect the self-hosted Docker image and Trigger.dev Cloud:
- Favorite any dashboard page to a new Favorites section in the side
menu, and customize the sidebar by renaming favorites, hiding items, and
reordering items and sections.
([#4375](#4375))
- List API endpoints now clamp the page size to a maximum of 100.
Requests asking for a larger page size return up to 100 items and keep
paginating, rather than pulling an unbounded page.
([#4360](#4360))
- Organizations without billing alerts now get default spend alert
thresholds, so you're notified before usage grows unexpectedly. The
billing limit page no longer pre-selects an option before you've set a
limit and prompts you to configure one. Alert previews now update
immediately after you change your billing limit.
([#4328](#4328))
- When you create a Personal Access Token, the generated token now shows
its first and last few characters instead of being fully hidden, so you
can confirm you copied the right value.
([#4363](#4363))
- Add metrics to the realtime backend that measure how often a single
changed run is served to multiple subscriptions in one batch.
([#4341](#4341))
- Realtime run subscriptions can now be configured to read run data
straight from the primary database, so a run's latest state is never
served from a lagging replica. Off by default; replica reads are
unchanged unless you turn it on.
([#4378](#4378))
- SSO and Directory Sync are no longer restricted to Enterprise plans —
get in touch and we can turn them on for your organization whatever plan
you're on.
([#4393](#4393))
- Improved supervisor observability: it now reports metrics for its
outbound requests, making failed calls to upstream services easier to
monitor.
([#4350](#4350))
- The runs list on a task's page now updates live — run statuses change
and newly triggered runs appear without a manual refresh, matching the
main Runs page.
([#4377](#4377))
- Speed up the Batches list page for environments with a large number of
batches, which could previously time out while loading.
([#4361](#4361))
- Container startup no longer prints database and ClickHouse connection
strings (with credentials) to the logs.
([#4346](#4346))
- The tasks page no longer runs two queries whose results were never
displayed, cutting wasted work on every page load and removing a source
of hidden server errors
([#4380](#4380))
<details>
<summary>Raw changeset output</summary>
# Releases
## @trigger.dev/build@4.5.8
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.5.8`
## trigger.dev@4.5.8
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.5.8`
- `@trigger.dev/build@4.5.8`
- `@trigger.dev/schema-to-json@4.5.8`
## @trigger.dev/core@4.5.8
### Patch Changes
- Allow additional environment API keys to create scoped public access
tokens through the Trigger.dev API. Use server-issued public access
tokens for batch operations so environment-scoped API keys can read
batch results.
([#4387](#4387))
## @trigger.dev/python@4.5.8
### Patch Changes
- Updated dependencies:
- `@trigger.dev/sdk@4.5.8`
- `@trigger.dev/core@4.5.8`
- `@trigger.dev/build@4.5.8`
## @trigger.dev/react-hooks@4.5.8
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.5.8`
## @trigger.dev/redis-worker@4.5.8
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.5.8`
## @trigger.dev/rsc@4.5.8
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.5.8`
## @trigger.dev/schema-to-json@4.5.8
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.5.8`
## @trigger.dev/sdk@4.5.8
### Patch Changes
- Preserve the partial assistant message when a chat turn's model stream
fails mid-response. `chat.agent` now passes the recovered partial to
`onTurnComplete`, and `chat.createSession`'s `turn.complete()` keeps it
before rethrowing, instead of dropping the streamed-so-far output.
([#4348](#4348))
- Allow additional environment API keys to create scoped public access
tokens through the Trigger.dev API. Use server-issued public access
tokens for batch operations so environment-scoped API keys can read
batch results.
([#4387](#4387))
- Updated dependencies:
- `@trigger.dev/core@4.5.8`
</details>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Summary
The realtime runs feed hydrates run rows from read replicas, which means it needs a replica-lag gate to avoid serving a run's previous state right after a write. Setting
REALTIME_BACKEND_NATIVE_RUN_READS_FROM_PRIMARY=1reads those rows from each run store's primary instead, so there is no lag to gate against: no probe, no wake delay, no stale-read retries. Off by default, so nothing changes unless you set it.Design
The run stores already decide replica-vs-primary from the brand on the read client they are handed: a branded replica keeps the read on the owning store's replica, an unbranded writer escalates it to that store's own primary. So this is a one-line choice at the hydrator, and it stays correct across topologies. With the run-ops split on, each leg lands on its own writer and the caller's client is never forwarded across databases; with the split off, it is the single database's primary.
The same flag skips constructing the lag estimator, since probing a replica the feed no longer reads would be measuring the wrong thing.
Independently,
AuroraReplicaLagSourcedetected Aurora by lettingaurora_replica_status()fail, on the assumption that the app-level catch made that free. It isn't: an unresolvable function is a query error the driver reports to the error log on every sample, so a non-Aurora replica produced a continuous stream of error events while the estimator quietly fell through to its next candidate. It now resolves the function withto_regprocand memoizes the answer, so the unparseable call never reaches the wire.