Skip to content
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.

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

detect nodejs side by side pulumi for inline automation programs and fail fast #7349

Merged
merged 2 commits into from
Jun 23, 2021

Conversation

EvanBoyle
Copy link
Contributor

Description

This change detects when nodejs automation api inline programs load multiple instances of @pulumi/pulumi and triggers an early failure with a helpful error message:

      pulumi:pulumi:Stack (inlineNode-dev):
          error: Unhandled exception: Error: Detected multiple versions of '@pulumi/pulumi' in use in an inline automation api program
          Use the yarn 'resolutions' field to resolve this: https://github.com/pulumi/pulumi/issues/5449.

Using multiple versions of pulumi/pulumi in inline programs can cause collisions in global state. Until we address #5449, inline node automation users need to pin to a single version of pulumi/pulumi to avoid issues like those seen in #6998

This change set adds a module level global (a random number) that each instance of pulumi/pulumi will write into the environment. We detect side by side scenarios by comparing the module level global to the value in the environment every time we observe settings, or do a resource operation (invoke, register resource, get, etc).

Fixes #7333

Checklist

  • I have added tests that prove my fix is effective or that my feature works

Copy link
Member

@komalali komalali left a comment

Choose a reason for hiding this comment

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

LGTM


// if we see a different identifier, another version of pulumi has been loaded and we should fail.
if (!!envSxS && envSxS !== sxsRandomIdentifier) {
throw new Error("Detected multiple versions of '@pulumi/pulumi' in use in an inline automation api program.\n" +
Copy link
Member

Choose a reason for hiding this comment

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

Would be good to think about how to possibly link to docs with an example resolution in errors like this.

justinvp added a commit that referenced this pull request Oct 10, 2023
This change removes the SxS check in the Node.js Automation API since it's blocking a customer scenario and isn't needed anymore now that #5449 has been addressed with #10568.

The check was originally added in #7349 to provide a helpful error message when multiple versions of `@pulumi/pulumi` were used with inline programs, which could cause clashes with global state. Since then, we've changed how state is stored to allow parallel execution of multiple inline programs with #10568. However, the SxS checks were not removed as part of that change.

A customer recently hit the error associated with the SxS check. They are creating a Next.js program that runs Pulumi operations as inline programs. Next.js ends up loading modules multiple times in a way that confuses the SxS checker, causing the error to be thrown, even though it wouldn't have been a problem.
justinvp added a commit that referenced this pull request Oct 10, 2023
This change removes the SxS check in the Node.js Automation API since it's blocking a customer scenario and isn't needed anymore now that #5449 has been addressed with #10568.

The check was originally added in #7349 to provide a helpful error message when multiple versions of `@pulumi/pulumi` were used with inline programs, which could cause clashes with global state. Since then, we've changed how state is stored to allow parallel execution of multiple inline programs with #10568. However, the SxS checks were not removed as part of that change.

A customer recently hit the error associated with the SxS check. They are creating a Next.js program that runs Pulumi operations as inline programs. Next.js ends up loading modules multiple times in a way that confuses the SxS checker, causing the error to be thrown, even though it wouldn't have been a problem.
github-merge-queue bot pushed a commit that referenced this pull request Oct 11, 2023
This change removes the SxS check in the Node.js Automation API since
it's blocking a customer scenario and isn't needed anymore now that
#5449 has been addressed with #10568.

The check was originally added in #7349 to provide a helpful error
message when multiple versions of `@pulumi/pulumi` were used with inline
programs, which could cause clashes with global state. Since then, we've
changed how state is stored to allow parallel execution of multiple
inline programs with #10568. However, the SxS checks were not removed as
part of that change.

A customer recently hit the error associated with the SxS check. They
are creating a Next.js program that runs Pulumi operations as inline
programs. Next.js ends up loading modules multiple times in a way that
confuses the SxS checker, causing the error to be thrown, even though it
wouldn't have been a problem.

Fixes #14128
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

NodeJS Automation API - detect side by side @pulumi/pulumi and fail early
3 participants