Skip to content

fix(sdk): resolve undefined name variable in updateEnvVar overload #4494

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
okxint wants to merge 2 commits into from
Closed

fix(sdk): resolve undefined name variable in updateEnvVar overload #4494

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
457ba83
fix(sdk): resolve undefined name in updateEnvVar overload implementation
okxint Aug 3, 2026
19c99f2
chore: add changeset for updateEnvVar name scope fix
okxint Aug 3, 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
5 changes: 5 additions & 0 deletions .changeset/fix-update-env-var-name-scope.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
---
"@trigger.dev/sdk": patch
---

Fix `updateEnvVar` incorrectly reading from an out-of-scope variable when called with the `(projectRef, slug, name, params)` overload. The `name` parameter was undefined in the implementation body; it now correctly reads from `nameOrRequestOptions`.

@devin-ai-integration devin-ai-integration Bot Aug 3, 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.

🟡 Release note text describes internals instead of user-facing behavior

The release note text added for this change describes internal implementation details (.changeset/fix-update-env-var-name-scope.md:5) rather than the user-visible behavior, which the repository guidelines require.
Impact: Users reading the published release notes see internal variable names instead of a plain description of what was fixed.

Repository rule from AGENTS.md on changeset wording

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 current text mentions "out-of-scope variable", "the implementation body" and the internal parameter name nameOrRequestOptions.

Suggested change
Fix `updateEnvVar` incorrectly reading from an out-of-scope variable when called with the `(projectRef, slug, name, params)` overload. The `name` parameter was undefined in the implementation body; it now correctly reads from `nameOrRequestOptions`.
Fixed updating an environment variable with an explicit project ref, slug and name sending an empty name, so the update now applies to the variable you specified.
Open in Devin Review

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

2 changes: 1 addition & 1 deletion packages/trigger-sdk/src/v3/envvars.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -338,7 +338,7 @@ export function update(

$projectRef = projectRefOrName;
$slug = slugOrParams;
$name = name!;
$name = nameOrRequestOptions as string;

@devin-ai-integration devin-ai-integration Bot Aug 3, 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.

🔴 Updating an environment variable from inside a running task still targets the wrong project

When the four-argument form is used from inside a running task, the project identifier is taken from the slug argument instead of the project argument ($projectRef = slugOrParams at packages/trigger-sdk/src/v3/envvars.ts:308), so the update is sent to a non-existent project and fails.
Impact: Users calling the update helper with an explicit project and slug from within a task get a failed/incorrect update instead of the variable being changed.

Why the fix is incomplete: only the no-task-context branch was corrected

The implementation signature is (projectRefOrName, slugOrParams, nameOrRequestOptions, params, requestOptions). The PR fixed the else branch (no task context) at packages/trigger-sdk/src/v3/envvars.ts:339-342, which now correctly maps projectRefOrName -> $projectRef, slugOrParams -> $slug, nameOrRequestOptions -> $name.

But inside a task (taskContext.ctx truthy) the very same overload takes packages/trigger-sdk/src/v3/envvars.ts:307-319, where:

  • $projectRef = slugOrParams (the slug, not the project ref)
  • $slug = slugOrParams ?? ... (the ?? is dead since slugOrParams is a string here)
  • $name falls back to taskContext.ctx.environment.slug when the name is missing, which would silently update a variable named after the environment.

Compare with retrieve (packages/trigger-sdk/src/v3/envvars.ts:208-219) and del (packages/trigger-sdk/src/v3/envvars.ts:255-266) which correctly use projectRefOrName for $projectRef.

Prompt for agents 
In packages/trigger-sdk/src/v3/envvars.ts, the `update` implementation resolves its arguments differently depending on whether `taskContext.ctx` exists. The PR fixed the no-context branch so that `$name` comes from `nameOrRequestOptions`, but the in-task branch (the `if (taskContext.ctx)` / `typeof slugOrParams === 'string'` path) still assigns `$projectRef = slugOrParams`, i.e. it uses the slug as the project reference, and it defaults `$name` to the environment slug when no name is supplied. For the `(projectRef, slug, name, params)` overload the mapping should be identical in both branches: `$projectRef = projectRefOrName`, `$slug = slugOrParams`, `$name = nameOrRequestOptions`. Consider unifying the argument resolution for the two branches (see how `retrieve` and `del` in the same file do it) so the in-task path is not broken.
Open in Devin Review

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

@devin-ai-integration devin-ai-integration Bot Aug 3, 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.

🔍 Second overload (name, params) still unusable outside a task context

Overload 2 declares update(name, params, requestOptions?). Outside a task context that call lands in the else branch at packages/trigger-sdk/src/v3/envvars.ts:327-329, where slugOrParams is the params object, so it throws "slug is required" — arguably correct (no project/env known), but the thrown message is misleading for that call shape. Worth confirming the intended error message/behaviour while touching this function.

Open in Devin Review

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

$params = params;
}

Expand Down