Skip to content

fix(cli-v3): forward TRIGGER_WORKER_INSTANCE_NAME into the managed run process env #4213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
brentshulman-silkline wants to merge 2 commits into from
Closed

fix(cli-v3): forward TRIGGER_WORKER_INSTANCE_NAME into the managed run process env #4213

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a4de2d0
fix(cli-v3): forward TRIGGER_WORKER_INSTANCE_NAME into managed run pr…
brentshulman-silkline Jul 9, 2026
dcd100b
chore: add changeset for TRIGGER_WORKER_INSTANCE_NAME env forward
brentshulman-silkline Jul 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions .changeset/forward-worker-instance-name.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
---
"trigger.dev": patch
---

Forward `TRIGGER_WORKER_INSTANCE_NAME` into the managed run process env

The Kubernetes workload manager already injects `TRIGGER_WORKER_INSTANCE_NAME`
(= `spec.nodeName`) into the run-controller container via the downward API, but
the managed run worker is forked with an explicit env allowlist
(`RunnerEnv.gatherProcessEnv()`) that dropped it. As a result the run process
could not attach the node as an OpenTelemetry `host.name` resource attribute, so
spans/logs exported to an off-node OTLP collector had no host (Datadog tags these
`issue_type:empty_hostname`). This forwards the value so `trigger.config.ts`
telemetry (or the worker itself) can surface the node/host.
Comment on lines +5 to +14

@devin-ai-integration devin-ai-integration Bot Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changeset description uses internal jargon instead of user-facing language

The changeset body names internal infrastructure and code paths (RunnerEnv.gatherProcessEnv(), Kubernetes downward API, Datadog, OTLP collector) (.changeset/forward-worker-instance-name.md:5-14), violating the repo rule that changeset descriptions must be written for users, not maintainers.

Impact: Internal implementation details will appear verbatim in public release notes, confusing end users.

Repo rule violation details

AGENTS.md states: "Write the description for users, not maintainers. Both changesets and .server-changes/ notes ship verbatim in user-visible release notes. Lead with what changed for the user - one plain sentence describing behavior, not implementation, and never naming internal tools or infra."

The .server-changes/README.md:47-48 reinforces: "Never name internal tools or infra. Observability stacks, internal services, infra components, monitoring backends, CI surfaces, AWS specifics - none of these belong in user-facing notes."

The current changeset body mentions: Kubernetes workload manager, downward API, RunnerEnv.gatherProcessEnv(), OpenTelemetry, OTLP collector, Datadog, trigger.config.ts telemetry internals. All of these are internal implementation details.

Suggested change
Forward `TRIGGER_WORKER_INSTANCE_NAME` into the managed run process env
The Kubernetes workload manager already injects `TRIGGER_WORKER_INSTANCE_NAME`
(= `spec.nodeName`) into the run-controller container via the downward API, but
the managed run worker is forked with an explicit env allowlist
(`RunnerEnv.gatherProcessEnv()`) that dropped it. As a result the run process
could not attach the node as an OpenTelemetry `host.name` resource attribute, so
spans/logs exported to an off-node OTLP collector had no host (Datadog tags these
`issue_type:empty_hostname`). This forwards the value so `trigger.config.ts`
telemetry (or the worker itself) can surface the node/host.
Forward the worker/node name into managed run processes so custom telemetry exporters can identify which host executed each run
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

5 changes: 5 additions & 0 deletions packages/cli-v3/src/entryPoints/managed/env.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -236,6 +236,11 @@ export class RunnerEnv {
OTEL_EXPORTER_OTLP_ENDPOINT: this.OTEL_EXPORTER_OTLP_ENDPOINT,
TRIGGER_OTEL_EXPORTER_OTLP_ENDPOINT: this.OTEL_EXPORTER_OTLP_ENDPOINT,
UV_USE_IO_URING: this.UV_USE_IO_URING,
// Forward the worker instance name (spec.nodeName on k8s) into the run
// process so it can be attached as an OTEL host/node resource attribute.
// Without this, run spans/logs exported to an off-node OTLP collector
// have no host and Datadog tags them issue_type:empty_hostname.
TRIGGER_WORKER_INSTANCE_NAME: this.TRIGGER_WORKER_INSTANCE_NAME,
};

// Filter out undefined values
Expand Down