41a486ea7e
🚀 Publish Trigger.dev Docker / typecheck (push) Failing after 0s
🚀 Publish Trigger.dev Docker / publish-webapp (push) Has been skipped
🚀 Publish Trigger.dev Docker / publish-worker (push) Has been skipped
🚀 Publish Trigger.dev Docker / publish-worker-v4 (push) Has been skipped
🚀 Publish Trigger.dev Docker / units (push) Failing after 5s
🧭 Helm Chart Release / lint-and-test (push) Has been cancelled
🧭 Helm Chart Release / release (push) Has been cancelled
## Summary
1 improvement, 1 bug fix.
## Improvements
- Fail attempts on uncaught exceptions instead of hanging to
`MAX_DURATION_EXCEEDED`. A Node `EventEmitter` (e.g. `node-redis`)
emitting `"error"` with no `.on("error", ...)` listener escalates to
`uncaughtException`, which the worker previously reported but did not
act on — runs drifted to maxDuration with empty attempts. They now fail
fast with the original error and status `FAILED`, and respect the task's
normal retry policy. You should still attach `.on("error", ...)`
listeners to long-lived clients to handle errors gracefully.
([#3529](https://github.com/triggerdotdev/trigger.dev/pull/3529))
## Bug fixes
- Fix dev workers spinning at 100% CPU after the parent CLI disconnects.
Orphaned `trigger-dev-run-worker` (and indexer) processes were caught in
an `uncaughtException` feedback loop: a periodic IPC send via
`process.send` would throw `ERR_IPC_CHANNEL_CLOSED` once the parent
closed the channel, which re-entered the same handler that itself called
`process.send`, scheduled via `setImmediate` and amplified by
source-map-support's `prepareStackTrace`. Fixed by (1) silently dropping
packets in `ZodIpcConnection` when the channel is disconnected, (2)
adding a `process.on("disconnect", ...)` handler in dev workers so they
exit cleanly when the CLI closes the IPC channel, and (3) wrapping all
`uncaughtException`-path `process.send` calls in a `safeSend` guard that
checks `process.connected` and swallows synchronous throws.
([#3491](https://github.com/triggerdotdev/trigger.dev/pull/3491))
<details>
<summary>Raw changeset output</summary>
# Releases
## @trigger.dev/build@4.4.6
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.4.6`
## trigger.dev@4.4.6
### Patch Changes
- Fix dev workers spinning at 100% CPU after the parent CLI disconnects.
Orphaned `trigger-dev-run-worker` (and indexer) processes were caught in
an `uncaughtException` feedback loop: a periodic IPC send via
`process.send` would throw `ERR_IPC_CHANNEL_CLOSED` once the parent
closed the channel, which re-entered the same handler that itself called
`process.send`, scheduled via `setImmediate` and amplified by
source-map-support's `prepareStackTrace`. Fixed by (1) silently dropping
packets in `ZodIpcConnection` when the channel is disconnected, (2)
adding a `process.on("disconnect", ...)` handler in dev workers so they
exit cleanly when the CLI closes the IPC channel, and (3) wrapping all
`uncaughtException`-path `process.send` calls in a `safeSend` guard that
checks `process.connected` and swallows synchronous throws.
([#3491](https://github.com/triggerdotdev/trigger.dev/pull/3491))
- Fail attempts on uncaught exceptions instead of hanging to
`MAX_DURATION_EXCEEDED`. A Node `EventEmitter` (e.g. `node-redis`)
emitting `"error"` with no `.on("error", ...)` listener escalates to
`uncaughtException`, which the worker previously reported but did not
act on — runs drifted to maxDuration with empty attempts. They now fail
fast with the original error and status `FAILED`, and respect the task's
normal retry policy. You should still attach `.on("error", ...)`
listeners to long-lived clients to handle errors gracefully.
([#3529](https://github.com/triggerdotdev/trigger.dev/pull/3529))
- Updated dependencies:
- `@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
- Fix dev workers spinning at 100% CPU after the parent CLI disconnects.
Orphaned `trigger-dev-run-worker` (and indexer) processes were caught in
an `uncaughtException` feedback loop: a periodic IPC send via
`process.send` would throw `ERR_IPC_CHANNEL_CLOSED` once the parent
closed the channel, which re-entered the same handler that itself called
`process.send`, scheduled via `setImmediate` and amplified by
source-map-support's `prepareStackTrace`. Fixed by (1) silently dropping
packets in `ZodIpcConnection` when the channel is disconnected, (2)
adding a `process.on("disconnect", ...)` handler in dev workers so they
exit cleanly when the CLI closes the IPC channel, and (3) wrapping all
`uncaughtException`-path `process.send` calls in a `safeSend` guard that
checks `process.connected` and swallows synchronous throws.
([#3491](https://github.com/triggerdotdev/trigger.dev/pull/3491))
- Fail attempts on uncaught exceptions instead of hanging to
`MAX_DURATION_EXCEEDED`. A Node `EventEmitter` (e.g. `node-redis`)
emitting `"error"` with no `.on("error", ...)` listener escalates to
`uncaughtException`, which the worker previously reported but did not
act on — runs drifted to maxDuration with empty attempts. They now fail
fast with the original error and status `FAILED`, and respect the task's
normal retry policy. You should still attach `.on("error", ...)`
listeners to long-lived clients to handle errors gracefully.
([#3529](https://github.com/triggerdotdev/trigger.dev/pull/3529))
## @trigger.dev/python@4.4.6
### Patch Changes
- Updated dependencies:
- `@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
- Updated dependencies:
- `@trigger.dev/core@4.4.6`
## @trigger.dev/redis-worker@4.4.6
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.4.6`
## @trigger.dev/rsc@4.4.6
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.4.6`
## @trigger.dev/schema-to-json@4.4.6
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.4.6`
## @trigger.dev/sdk@4.4.6
### Patch Changes
- Updated dependencies:
- `@trigger.dev/core@4.4.6`
</details>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Python Extension for Trigger.dev
The Python extension enhances Trigger.dev's build process by enabling limited support for executing Python scripts within your tasks.
Overview
This extension introduces the pythonExtension build extension, which offers several key capabilities:
- Install Python Dependencies (Except in Dev): Automatically installs Python and specified dependencies using
pip. - Requirements File Support: You can specify dependencies in a
requirements.txtfile. - Inline Requirements: Define dependencies directly within your
trigger.config.tsfile using therequirementsoption. - Virtual Environment: Creates a virtual environment (
/opt/venv) inside containers to isolate Python dependencies. - Helper Functions: Provides a variety of functions for executing Python code:
run: Executes Python commands with proper environment setup.runInline: Executes inline Python code directly from Node.runScript: Executes standalone.pyscript files.
- Custom Python Path: In development, you can configure
devPythonBinaryPathto point to a custom Python installation.
Usage
- Add the extension to your
trigger.config.tsfile:
import { defineConfig } from "@trigger.dev/sdk/v3";
import { pythonExtension } from "@trigger.dev/python/extension";
export default defineConfig({
project: "<project ref>",
build: {
extensions: [
pythonExtension({
requirementsFile: "./requirements.txt", // Optional: Path to your requirements file
devPythonBinaryPath: ".venv/bin/python", // Optional: Custom Python binary path
scripts: ["src/python/**/*.py"], // Glob pattern for Python scripts
}),
],
},
});
- (Optional) Create a
requirements.txtfile in your project root with the necessary Python dependencies.
pandas==1.3.3
numpy==1.21.2
import { defineConfig } from "@trigger.dev/sdk/v3";
import { pythonExtension } from "@trigger.dev/python/extension";
export default defineConfig({
project: "<project ref>",
build: {
extensions: [
pythonExtension({
requirementsFile: "./requirements.txt",
}),
],
},
});
- Execute Python scripts within your tasks using one of the provided functions:
Running a Python Script
import { task } from "@trigger.dev/sdk/v3";
import { python } from "@trigger.dev/python";
export const myScript = task({
id: "my-python-script",
run: async () => {
const result = await python.runScript("my_script.py", ["hello", "world"]);
return result.stdout;
},
});
export const myStreamingScript = task({
id: "my-streaming-python-script",
run: async () => {
// You can also stream the output of the script
const result = python.stream.runScript("my_script.py", ["hello", "world"]);
// result is an async iterable/readable stream
for await (const chunk of streamingResult) {
logger.debug("convert-url-to-markdown", {
url: payload.url,
chunk,
});
}
},
});
Running Inline Python Code
import { task } from "@trigger.dev/sdk/v3";
import { python } from "@trigger.dev/python";
export const myTask = task({
id: "to_datetime-task",
run: async () => {
const result = await python.runInline(`
import pandas as pd
pd.to_datetime("${+new Date() / 1000}")
`);
return result.stdout;
},
});
Running Lower-Level Commands
import { task } from "@trigger.dev/sdk/v3";
import { python } from "@trigger.dev/python";
export const pythonVersionTask = task({
id: "python-version-task",
run: async () => {
const result = await python.run(["--version"]);
return result.stdout; // Expected output: Python 3.12.8
},
});
Limitations
- This is a partial implementation and does not provide full Python support as an execution runtime for tasks.
- Manual intervention may be required for installing and configuring binary dependencies in development environments.
Additional Information
For more detailed documentation, visit the official docs at Trigger.dev Documentation.