Skip to content

Releases: triggerdotdev/trigger.dev

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

Patch Changes

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

Patch Changes

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

Patch Changes

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

Patch Changes

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

Patch Changes

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

Patch Changes

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

@trigger.dev/[email protected]

21 Aug 16:46
5b40c44
Compare
Choose a tag to compare

Patch Changes

[email protected]

18 Aug 11:39
0b35cc3
Compare
Choose a tag to compare

Major Changes

Patch Changes

  • Make the default of legacyDevProcessCwdBehaviour true instead of false (prevents breaking prismaExtension) (#2387)
  • Added experimental_devProcessCwdInBuildDir config option to opt-in to new process.cwd behavior when executing tasks in the dev CLI. Currently process.cwd maps to the "root" of your trigger.dev project (the directory that contains your trigger.config.ts file). Setting experimental_devProcessCwdInBuildDir to true changes process.cwd to instead be the temporary build directory inside of the .trigger directory. (#2269)
  • Fix dev runs (#2094)
  • The dev command will now use the platform-provided engine URL (#1949)
  • Run Engine 2.0 (alpha) (#1575)
  • Fix update command version mismatch detection (#2199)
  • fix: prevent circular reference errors on task indexing when using schemaTask (#2383)
  • Add external log exporters and fix missing external trace exporters in deployed tasks (#2038)
  • Allow any runs to finish after SIGTERM but disable warm starts (#2316)
  • Gracefully shutdown task run processes using SIGTERM followed by SIGKILL after a 1s timeout. This also prevents cancelled or completed runs from leaving orphaned Ttask run processes behind (#2299)
  • Enhance deploy command output to better distinguish between local and remote builds (#2254)
  • Switch to profile after successful login (#2192)
  • Fixes a bug that would allow processes that had OOM errors to be incorrectly reused when experimental_processKeepAlive was enabled (#2261)
  • Runtime agnostic SDK config via env vars (#2132)
  • improve contrast for chalkWorker in light mode (#2239)
  • Expose esbuild keepNames option (experimental) (#2091)
  • Add experimental_autoDetectExternal trigger config option (#2083)
  • Add project details to the whoami command (#2231)
  • fix: waitUntil now correctly waits for metadata.streams to finish (#2399)
  • Log images sizes for self-hosted deploys (#1764)
  • Display clickable links in Cursor terminal (#1998)
  • Fix init.ts in custom trigger dirs (#1914)
  • Add import timings and bundle size analysis, the dev command will now warn about slow imports (#2114)
  • Fix update command version range handling (#2153)
  • All experimental flags have been promoted to non-experimental, but the experimental ones still work (for now). keepNames and autoDetectExternal now default to true. (#2371)
  • fix(runner): prevent retry immediately race condition which can cause stuck runs that end up being system failures (#2402)
  • Upgrade to bun v1.2.20 (#2398)
  • Init command will now correctly install v4-beta packages (#1914)
  • Fix metadata collapsing correctness (#2115)
  • Improve warm start times by eagerly creating the child TaskRunProcess when a previous run as completed (#1879)
    • Resolve issue where CLI could get stuck during deploy finalization (#2138)
    • Unify local and remote build logic, with multi-platform build support
    • Improve switch command; now accepts profile name as an argument
    • Registry configuration is now fully managed by the webapp
    • The deploy --self-hosted flag is no longer required
    • Enhance deployment error reporting and image digest retrieval
  • Fix init.ts detection when using the sentry esbuild plugin (#2051)
    • Correctly resolve waitpoints that come in early (#2006)
    • Ensure correct state before requesting suspension
    • Fix race conditions in snapshot processing
  • experimental processKeepAlive (#2183)
  • Fixes runLimiter check on #dequeueRuns (#1953)
  • Update nypm package to support test-based bun.lock files (#1914)
  • Added AI assistance link when you have build errors (#1925)
  • Handle flush errors gracefully in dev (#1914)
    • Improve playwright non-headless chrome installation (#2347)
    • Prevent spinner message duplication in narrow terminals
  • Added support for Preview branches in v4 projects (#2086)
  • Can now set project ref using the TRIGGER_PROJECT_REF env var (#2109)
  • Add runtime version detection for display in the dashboard (#2254)
  • Update profile switcher (#2150)
  • Update base images to latest compatible versions. The node-22 runtime now uses v22.16.0 and bun uses the latest v1.2.18 release. The default node runtime is unchanged and points at v21.7.3. (#2254)
  • Improve usage flushing (#1931)
  • fix: default machine config indexing now works (#1979)
  • Prevent large outputs from overwriting each other (#1971)
  • Fail fast in CI when running deploy with missing TRIGGER_ACCESS_TOKEN and add useful error message with link to docs (#2258)
  • Always print full deploy logs in CI (#2006)
  • Upgrade to zod 3.25.76 (#2352)
  • TriggerApiError 4xx errors will no longer cause tasks to be retried (#1970)
    • Fix polling interval reset bug that could create duplicate intervals (#1987)
    • Protect against unexpected attempt number changes
    • Prevent run execution zombies after warm starts
  • Fix stalled run detection (#1934)
  • Managed run controller performance and reliability improvements (#1927)
  • Fix init.ts auto-import for deployed workers (#2041)
  • fix: external traces now respect parent sampling, and prevent broken traces when there is no external trace context (#2395)
  • v4: New lifecycle hooks (#1817)
  • Output esbuild metafile, can be inspected after deploy --dry run (#2087)
  • Fix QUEUED status snapshot handler (#1963)
  • Serialize metadata to prevent invalid metadata from breaking run completions (#2219)
  • If you pass a directory when calling deploy we validate it exists and give helpful hints (#2013)
  • Expose esbuild minify option (experimental) (#2091)
  • Fix syncEnvVars for non-preview deployments (#2131)
  • Updated dependencies:

@trigger.dev/[email protected]

18 Aug 11:39
0b35cc3
Compare
Choose a tag to compare

Major Changes

Patch Changes

  • fix: importing from runEngine/index.js breaks non-node runtimes (#2328)

  • Run Engine 2.0 (alpha) (#1575)

  • fix: Logging large objects is now much more performant and uses less memory (#2263)

  • New internal idempotency implementation for trigger and batch trigger to prevent request retries from duplicating work (#2256)

  • When you create a Waitpoint token using wait.createToken() you get a URL back that can be used to complete it by making an HTTP POST request. (#2025)

  • feat: Support AI SDK 5.0. ai.tool now accepts either a schemaTask or a task with a provided jsonSchema (#2396)

  • External Trace Correlation & OpenTelemetry Package Updates. (#2334)

    Package Previous Version New Version Change Type
    @opentelemetry/api 1.9.0 1.9.0 No change (stable API)
    @opentelemetry/api-logs 0.52.1 0.203.0 Major update
    @opentelemetry/core - 2.0.1 New dependency
    @opentelemetry/exporter-logs-otlp-http 0.52.1 0.203.0 Major update
    @opentelemetry/exporter-trace-otlp-http 0.52.1 0.203.0 Major update
    @opentelemetry/instrumentation 0.52.1 0.203.0 Major update
    @opentelemetry/instrumentation-fetch 0.52.1 0.203.0 Major update
    @opentelemetry/resources 1.25.1 2.0.1 Major update
    @opentelemetry/sdk-logs 0.52.1 0.203.0 Major update
    @opentelemetry/sdk-node 0.52.1 - Removed (functionality consolidated)
    @opentelemetry/sdk-trace-base 1.25.1 2.0.1 Major update
    @opentelemetry/sdk-trace-node 1.25.1 2.0.1 Major update
    @opentelemetry/semantic-conventions 1.25.1 1.36.0 Minor update

    External trace correlation and propagation

    We will now correlate your external traces with trigger.dev traces and logs when using our external exporters:

    import { defineConfig } from "@trigger.dev/sdk";
    import { OTLPLogExporter } from "@opentelemetry/exporter-logs-otlp-http";
    import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
    
    export default defineConfig({
      project: process.env.TRIGGER_PROJECT_REF,
      dirs: ["./src/trigger"],
      telemetry: {
        logExporters: [
          new OTLPLogExporter({
            url: "https://api.axiom.co/v1/logs",
            headers: {
              Authorization: `Bearer ${process.env.AXIOM_TOKEN}`,
              "X-Axiom-Dataset": "test",
            },
          }),
        ],
        exporters: [
          new OTLPTraceExporter({
            url: "https://api.axiom.co/v1/traces",
            headers: {
              Authorization: `Bearer ${process.env.AXIOM_TOKEN}`,
              "X-Axiom-Dataset": "test",
            },
          }),
        ],
      },
      maxDuration: 3600,
    });

    You can also now propagate your external trace context when calling back into your own backend infra from inside a trigger.dev task:

    import { otel, task } from "@trigger.dev/sdk";
    import { context, propagation } from "@opentelemetry/api";
    
    async function callNextjsApp() {
      return await otel.withExternalTrace(async () => {
        const headersObject = {};
    
        // Now context.active() refers to your external trace context
        propagation.inject(context.active(), headersObject);
    
        const result = await fetch("http://localhost:3000/api/demo-call-from-trigger", {
          headers: new Headers(headersObject),
          method: "POST",
          body: JSON.stringify({
            message: "Hello from Trigger.dev",
          }),
        });
    
        return result.json();
      });
    }
    
    export const myTask = task({
      id: "my-task",
      run: async (payload: any) => {
        await callNextjsApp();
      },
    });
  • Add jsonSchema support when indexing tasks (#2353)

  • Fixed an issue with realtime streams that timeout and resume streaming dropping chunks (#1993)

  • Added and cleaned up the run ctx param: (#2322)

    • New optional properties ctx.run.parentTaskRunId and ctx.run.rootTaskRunId reference the current run's root/parent ID.
    • Removed deprecated properties from ctx
    • Added a new ctx.deployment object that contains information about the deployment associated with the run.

    We also update metadata.root and metadata.parent to work even when the run is a "root" run (meaning it doesn't have a parent or a root associated run). This now works:

    metadata.root.set("foo", "bar");
    metadata.parent.set("baz", 1);
    metadata.current().foo; // "bar"
    metadata.current().baz; // 1
  • The envvars.list() and retrieve() functions receive isSecret for each value. Secret values are always redacted. (#1942)

  • Fix issue where realtime streams would cut off after 5 minutes (#1952)

  • Deprecate toolTask and replace with ai.tool(mySchemaTask) (#1863)

  • Display clickable links in Cursor terminal (#1998)

  • Removes the releaseConcurrencyOnWaitpoint option on queues and the releaseConcurrency option on various wait functions. Replaced with the following default behavior: (#2284)

    • Concurrency is never released when a run is first blocked via a waitpoint, at either the env or queue level.
    • Concurrency is always released when a run is checkpointed and shutdown, at both the env and queue level.

    Additionally, environment concurrency limits now have a new "Burst Factor", defaulting to 2.0x. The "Burst Factor" allows the environment-wide concurrency limit to be higher than any individual queue's concurrency limit. For example, if you have an environment concurrency limit of 100, and a Burst Factor of 2.0x, then you can execute up to 200 runs concurrently, but any one task/queue can still only execute 100 runs concurrently.

    We've done some work cleaning up the run statuses. The new statuses are:

    • PENDING_VERSION: Task is waiting for a version update because it cannot execute without additional information (task, queue, etc.)
    • QUEUED: Task is waiting to be executed by a worker
    • DEQUEUED: Task has been dequeued and is being sent to a worker to start executing.
    • EXECUTING: Task is currently being executed by a worker
    • WAITING: Task has been paused by the system, and will be resumed by the system
    • COMPLETED: Task has been completed successfully
    • CANCELED: Task has been canceled by the user
    • FAILED: Task has failed to complete, due to an error in the system
    • CRASHED: Task has crashed and won't be retried, most likely the worker ran out of resources, e.g. memory or storage
    • SYSTEM_FAILURE: Task has failed to complete, due to an error in the system
    • DELAYED: Task has been scheduled to run at a specific time
    • EXPIRED: Task has expired and won't be executed
    • TIMED_OUT: Task has reached it's maxDuration and has been stopped

    We've removed the following statuses:

    • WAITING_FOR_DEPLOY: This is no longer used, and is replaced by PENDING_VERSION
    • FROZEN: This is no longer used, and is replaced by WAITING
    • INTERRUPTED: This is no longer used
    • REATTEMPTING: This is no longer used, and is replaced by EXECUTING

    We've also added "boolean" helpers to runs returned via the API and from Realtime:

    • isQueued: Returns true when the status is QUEUED, PENDING_VERSION, or DELAYED
    • isExecuting: Returns true when the status is EXECUTING, DEQUEUED. These count against your concurrency limits.
    • isWaiting: Returns true when the status is WAITING. These do not count against your concurrency limits.
    • isCompleted: Returns true when the status is any of the completed statuses.
    • isCanceled: Returns true when the status is CANCELED
    • isFailed: Returns true when the status is any of the failed statuses.
    • isSuccess: Returns true when the status is COMPLETED

    This change adds the ability to easily detect which ...

Read more