fix: stop retrying silent chat streams indefinitely - #4949
Merged
ericallam merged 4 commits intoSep 17, 2026
Merged
Conversation
🦋 Changeset detectedLatest commit: 7825d1b The changes in this PR will be included in the next version bump. This PR includes changesets to release 27 packages
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 |
gtremper
marked this pull request as ready for review
September 17, 2026 18:26
Contributor
WalkthroughCore SSE streams now track stall retries separately from connection retries. Retry state resets only after decoded records. Internal abort exhaustion reports Priority: ⬇️ Low Merge Risk: 🔵 Low · up to A replacement stream can remain healthy while callers receive a spurious stream-error event from the old stream. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 4 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
ericallam
approved these changes
Sep 17, 2026
ericallam
enabled auto-merge
September 17, 2026 22:00
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to GitHub limitations.
🟡 Minor · Suppress stale stream-error events. · chat.ts:2442-2465
packages/trigger-sdk/src/v3/chat.ts:2442-2465
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winSuppress stale
stream-errorevents. The late token-refresh path can reject aftersendMessagesreplaces the old stream. The old stream then enters this non-abort handler whileactiveStreamspoints to the replacement. The current guard protects session state only; unconditionalemitEventnotifiesonEventof a false error for the active chat.Move the
stream-erroremission inside the existing ownership guard. Keepcontroller.error(error)outside the guard so the superseded reader still settles with its own error.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Advanced
Run ID: 29592fdc-bd49-47b9-85dc-50638f858213
📒 Files selected for processing (3)
.changeset/quiet-chat-stream-retries.mdpackages/core/src/v3/apiClient/runStream-retries.test.tspackages/core/src/v3/apiClient/runStream.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- .changeset/quiet-chat-stream-retries.md
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.
📜 Review details
⏰ Context from checks skipped due to timeout. (17)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (17, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (19, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (18, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (11, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (21, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (20, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (16, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (15, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (12, 24)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (13, 24)
- GitHub Check: e2e / 🧪 CLI v3 tests (warp-windows-latest-x64-8x - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (warp-windows-latest-x64-8x - pnpm)
- GitHub Check: e2e-webapp / 🧪 E2E Tests: Webapp (1, 2)
- GitHub Check: internal / 🧪 Unit Tests: Internal (2)
- GitHub Check: internal / 🧪 Unit Tests: Internal (1)
- GitHub Check: packages / 🧪 Unit Tests: Packages (3, 3)
- 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/apiClient/runStream-retries.test.tspackages/core/src/v3/apiClient/runStream.ts
Use zod for validation in packages/core and apps/webapp
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
packages/core/src/v3/apiClient/runStream-retries.test.tspackages/core/src/v3/apiClient/runStream.ts
Never import the root package (`@trigger.dev/core`).
📄 CodeRabbit inference engine (packages/core/CLAUDE.md)
Files:
packages/core/src/v3/apiClient/runStream-retries.test.tspackages/core/src/v3/apiClient/runStream.ts
Use vitest for all tests in the Trigger.dev repository
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
packages/core/src/v3/apiClient/runStream-retries.test.ts
Use function declarations instead of default exports
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
packages/core/src/v3/apiClient/runStream-retries.test.tspackages/core/src/v3/apiClient/runStream.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/apiClient/runStream-retries.test.tspackages/core/src/v3/apiClient/runStream.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/apiClient/runStream-retries.test.tspackages/core/src/v3/apiClient/runStream.ts
🔇 Additional comments (2)
packages/core/src/v3/apiClient/runStream.ts (1)
224-224: LGTM!Also applies to: 300-300, 658-663
packages/core/src/v3/apiClient/runStream-retries.test.ts (1)
86-86: LGTM!Also applies to: 121-121, 134-134, 185-185
Merged
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the server returns
200without records, chat subscriptions can retry indefinitely. The client stall timer fires after 60 seconds, before S2 closes the response at its 120-second timeout, so the existing EOF budget never applies. Terminal failures also leave persistedisStreamingstate active, so a reload starts another subscription.Normal chat subscriptions now permit five reconnects after stall timeouts. A separate stall counter preserves unlimited retries for retryable connection failures, fetch timeouts, and browser wakeups. Decoded records restore the stall budget. Terminal failures clear state only for the owning subscription, and watch subscriptions remain unlimited.
The existing stall timer already ignores keepalives because the parser drops them before the timer reset. The comment correction does not change that behavior.
Checklist
Testing
8149b96: 695 SDK tests and 1,122 core tests passed.apps/webapp/app/services/previewAutoArchive.server.ts; the changed files contain none.The tests use local HTTP servers. They cover separate stall limits, fetch timeouts, body failures, keepalives, progress resets, mixed failures, wakeups, cancellation, watch recovery, and replacement ownership. Core tests exercise stall exhaustion with short timers. The SDK's six-minute silence window needs reference-project validation.
Changelog
Silent chat subscriptions now report
Stream stalled: no records receivedafter five stall retries. Network failures retain automatic recovery, and watch subscriptions remain unlimited.Risk
onlineeventWith immediate response headers, six silent attempts take 368.5–377 seconds, about 6.1–6.3 minutes. Network delays extend this window. A healthy tool call with no records can also reach this limit: silence does not prove that the run is dead. The terminal error stops automatic client resumption but does not cancel the server-side run.
Shared core consumers retain their configured retry limits. Repeated successful responses without records now increase backoff until a decoded record arrives. Caller cancellation and token-refresh limits remain unchanged.