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

In-built support for getValue #13568

Open
ffMathy opened this issue Jul 24, 2023 · 2 comments
Open

In-built support for getValue #13568

ffMathy opened this issue Jul 24, 2023 · 2 comments
Labels
customer/feedback Feedback from customers kind/enhancement Improvements or new features

Comments

@ffMathy
Copy link
Contributor

ffMathy commented Jul 24, 2023

See this repo: https://github.com/LEGO/pulumi-get-value

I think this should be supported by Pulumi out of the box, both for dotnet and JavaScript (all languages supporting promises).

It can really make the call chain super clean, and make it easier to understand.

@ffMathy ffMathy added kind/enhancement Improvements or new features needs-triage Needs attention from the triage team labels Jul 24, 2023
@Zaid-Ajaj
Copy link
Contributor

Hi @ffMathy I've looked at the source code of getValue:

export const getValue = async <T>(output: pulumi.Output<T>): Promise<T> => {
  return new Promise((resolve) => {
    output.apply((value) => {
      resolve(value);
    });
  });
};

It creates a promise that resolves to the value of the output. However, the callback inside apply is only executed when the output is known which is usually the case during pulumi up. During pulumi preview, await getValue(...) will never resolve for an unknown value and your program will hang.

Writing such a function requires that you also provide a default value when the output is unknown and returning it. You also lose the "secretness" information and the dependencies of the output when you await the value.

Generally this goes against the programming model of Pulumi where outputs flow from start to finish, applying transformations using Apply when necessary. However, we do acknowledge that it isn't the most straightforward way to write programs and we implemented Output helper functions (for example #12519) to them easier to work with.

Is there a specific piece of code you have that you are trying to simplify, we can have a look.

@Zaid-Ajaj Zaid-Ajaj removed the needs-triage Needs attention from the triage team label Jul 24, 2023
@Frassle
Copy link
Member

Frassle commented Jul 24, 2023

Yeh this is pretty unsafe. If an output is unknown the promise will just never resolve.
Further this drops all information about if the value should be secret and loses all the resource dependency information that's used to ensure deletes happen in the right order.

We understand that outputs are the hardest part of the Pulumi programming model, but they are not promises and trying to handle them with await just brings about a different set of more subtle problems.

@mnlumi mnlumi added the customer/feedback Feedback from customers label Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer/feedback Feedback from customers kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

4 participants