chore: release v4.4.6#3501
Open
github-actions[bot] wants to merge 1 commit intomainfrom
Open
Conversation
b577d8c to
78e90b9
Compare
nicktrn
pushed a commit
that referenced
this pull request
May 2, 2026
## Summary Delete 34 `.server-changes/*.md` files that should have been cleaned up automatically when v4.4.5 (#3406) was merged but were stranded by a workflow race. ## Why these are stale The `update-lockfile` job in `.github/workflows/changesets-pr.yml` is what cleans up consumed `.server-changes/*.md` files on the release branch. When v4.4.5 was merged on 2026-05-01, the post-merge workflow run on `main` failed at `pnpm install --frozen-lockfile` (stale lockfile in the merge commit), and `cancel-in-progress: true` cancelled the in-flight run from the previous push — so `update-lockfile` never reached the cleanup step. Result: the 34 files described changes that v4.4.5 already shipped, and they were re-appearing in the v4.4.6 release PR (#3501) under "Server changes" plus showing up as deletions in its diff. ## What this PR keeps - `fix-rollback-schedule-sync.md` — genuinely new for v4.4.6 (#3468), the only server change introduced after v4.4.5 - `README.md`, `.gitkeep` — directory infrastructure - `dev-cli-disconnect-md` — leaving alone (typo'd filename from March, no `.md` extension, not picked up by the cleanup glob anyway) ## After merge The next run of `changesets-pr.yml` will refresh #3501 with a "Server changes" section that only lists the v4.4.6 entry, and the only `.server-changes/` deletion in its diff will be `fix-rollback-schedule-sync.md`. ## Related - #3505 is the proper underlying fix — collapses the three-job graph into a single atomic commit by `changesets/action` so this race can't strand the cleanup again. This PR is just the one-time catch-up for the files that already got stranded.
78e90b9 to
d33a6d8
Compare
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
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.
Summary
1 bug fix.
Bug fixes
trigger-dev-run-worker(and indexer) processes were caught in anuncaughtExceptionfeedback loop: a periodic IPC send viaprocess.sendwould throwERR_IPC_CHANNEL_CLOSEDonce the parent closed the channel, which re-entered the same handler that itself calledprocess.send, scheduled viasetImmediateand amplified by source-map-support'sprepareStackTrace. Fixed by (1) silently dropping packets inZodIpcConnectionwhen the channel is disconnected, (2) adding aprocess.on("disconnect", ...)handler in dev workers so they exit cleanly when the CLI closes the IPC channel, and (3) wrapping alluncaughtException-pathprocess.sendcalls in asafeSendguard that checksprocess.connectedand swallows synchronous throws. (#3491)Raw changeset output
Releases
@trigger.dev/build@4.4.6
Patch Changes
@trigger.dev/core@4.4.6trigger.dev@4.4.6
Patch Changes
trigger-dev-run-worker(and indexer) processes were caught in anuncaughtExceptionfeedback loop: a periodic IPC send viaprocess.sendwould throwERR_IPC_CHANNEL_CLOSEDonce the parent closed the channel, which re-entered the same handler that itself calledprocess.send, scheduled viasetImmediateand amplified by source-map-support'sprepareStackTrace. Fixed by (1) silently dropping packets inZodIpcConnectionwhen the channel is disconnected, (2) adding aprocess.on("disconnect", ...)handler in dev workers so they exit cleanly when the CLI closes the IPC channel, and (3) wrapping alluncaughtException-pathprocess.sendcalls in asafeSendguard that checksprocess.connectedand swallows synchronous throws. (#3491)@trigger.dev/core@4.4.6@trigger.dev/build@4.4.6@trigger.dev/schema-to-json@4.4.6@trigger.dev/core@4.4.6
Patch Changes
trigger-dev-run-worker(and indexer) processes were caught in anuncaughtExceptionfeedback loop: a periodic IPC send viaprocess.sendwould throwERR_IPC_CHANNEL_CLOSEDonce the parent closed the channel, which re-entered the same handler that itself calledprocess.send, scheduled viasetImmediateand amplified by source-map-support'sprepareStackTrace. Fixed by (1) silently dropping packets inZodIpcConnectionwhen the channel is disconnected, (2) adding aprocess.on("disconnect", ...)handler in dev workers so they exit cleanly when the CLI closes the IPC channel, and (3) wrapping alluncaughtException-pathprocess.sendcalls in asafeSendguard that checksprocess.connectedand swallows synchronous throws. (#3491)@trigger.dev/python@4.4.6
Patch Changes
@trigger.dev/core@4.4.6@trigger.dev/build@4.4.6@trigger.dev/sdk@4.4.6@trigger.dev/react-hooks@4.4.6
Patch Changes
@trigger.dev/core@4.4.6@trigger.dev/redis-worker@4.4.6
Patch Changes
@trigger.dev/core@4.4.6@trigger.dev/rsc@4.4.6
Patch Changes
@trigger.dev/core@4.4.6@trigger.dev/schema-to-json@4.4.6
Patch Changes
@trigger.dev/core@4.4.6@trigger.dev/sdk@4.4.6
Patch Changes
@trigger.dev/core@4.4.6