Repository navigation
[pull] main from triggerdotdev:main - #751
Merged
Merged
Conversation
## Summary Switches the MinIO test and local development containers to Chainguard's maintained Docker Hub images because the previous Quay images are no longer publicly pullable. ## Fix Pins the multi-platform server and client images by digest. The local stack now uses the Chainguard client entrypoint for bucket initialization, while test containers keep client state in a writable temporary directory.
Closes #4979 Credit to @marcus-dk for finding and root-causing this in #4979, including the zod version bisect and the end-to-end confirmation with a patched worker. ## Summary `FLUSH` and `CANCEL` declare `callback: z.void()`, so the task run process acks them with `{ type: "ACK", id, message: undefined }`. Node's JSON IPC serialization drops the undefined `message` key. Under zod 4.4+ a `z.any()` object key is required at parse time (it was optional under zod 3 and 4.0–4.3), so `Packet.safeParse` rejects every such ack, `#handlePacket` returns silently, and `sendWithAck` waits out its full timeout. Because `zodIpc.ts` imports `zod/v4` and `@trigger.dev/core` resolves `zod` from the user's project, every project on zod ≥ 4.4 pays this on every run: ~6 s between the task finishing and the completion reaching the engine (FLUSH: 5 s + 1 s), and ~31 s on cancel. The fix makes the ACK packet's `message` optional again (`z.any().optional()`). Only the ACK packet can legitimately carry `undefined`, so the other packets are unchanged. ## ✅ Checklist - [x] I have followed every step in the [contributing guide](https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md) - [x] The PR title follows the convention. - [x] I ran and tested the code works --- ## Testing - Added `packages/core/test/zodIpc.test.ts`: forks a real child process (`test/fixtures/zodIpcChild.ts`) and sends `FLUSH` (void callback) and `PING` (payload callback) over Node's IPC channel, so the ack goes through the same JSON serialization as between a worker and its task run process. On `main` (zod 4.5.4 in this repo) the void-callback test fails with `sendWithAck() timeout`; with the fix it resolves immediately. - `pnpm run build --filter @trigger.dev/core` passes. - Production evidence from our self-hosted instance (`completed_at - started_at - usage_duration_ms` on successful runs): | SDK | runs | p10 gap | p50 gap | |---|---|---|---| | 4.5.12 | 2.6M | 179 ms | 244 ms | | 4.5.15 | 5.0M | 176 ms | 251 ms | | 4.6.0 | 1.6M | 6,162 ms | 6,196 ms | | 4.6.2 | 4.0M | 6,180 ms | 6,240 ms | --- ## Changelog 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. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Co-authored-by: Matt Aitken <matt@mattaitken.com>
Mono-RevId: b455565ff705ccad4d1bba3fe3e02b25fbcd063e
…ifest 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. Mono-RevId: 570c78ee09bc121ae8066a7e70848ae4509d74e3
Mono-RevId: 90559be02c928bd675173ec4a5ff2e8cb3319a7e
Mono-RevId: 6f35650c0ce4a1243998ab7fbb10545b321bb4c1
Chat agents now return to a durable wait when session activity does not deliver a matching message. Repeated wakes preserve the original turn timeout instead of leaving the run active until its maximum duration. Mono-RevId: f9bb2238bbd2ea663eaac75ce3d92106a83c1104
Simplify project creation by removing optional onboarding questions. Mono-RevId: a04b3112a96c1dcf6d20aaf9892339f026e1f3e7
… when queued batches time out ## Summary Under a burst of telemetry, the OpenTelemetry ingest worker pool could terminate its own healthy workers and then keep terminating every replacement, leaving a server rejecting every OTLP batch until the process was restarted. Batches that wait too long in the queue are now dropped individually, workers are only terminated when they are genuinely stuck on a single batch, and every worker termination is logged. ## Root cause The pool starts a task's timeout when the batch is enqueued, but the timeout handler treated any dispatched task as evidence of a stuck worker. When queue wait alone exceeded the budget, the first timer to fire belonged to a batch a healthy worker was actively computing, so that worker was terminated. Each replacement worker was handed the oldest queued batch, whose timer was already about to fire, and was terminated moments later. With respawn backoff at its cap the pool sat at zero workers indefinitely, and the termination path logged nothing. ## Fix - Track when a task is dispatched. On timeout the caller is still rejected, but the worker is only reaped once it has spent a full timeout computing that one task; otherwise a compute timer gives it the remaining budget and the worker returns to the idle set when it replies. Deadline arithmetic uses a monotonic clock so a wall-clock step cannot trigger sheds or reaps. - Before dispatch, shed queued tasks whose remaining budget is below a small floor (recorded as `outcome=stale` on `ingest.worker_pool.tasks`) so a free worker starts on a batch it can finish. - Log every reap with reason, task age, time since dispatch, queue depth and alive workers; aggregate shed counts into at most one debug line per second. - Timeout and respawn backoff are constructor options with unchanged defaults so the overload scenario is testable. The new tests reproduce the failure on the previous code (all respawns `reason=timeout`, zero alive workers, throughput frozen) and cover the late-reply and hang-after-queue-wait paths. Mono-RevId: 69295ed642e15b72d3ee8d15c6fe734e6579b94e
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )