Dealing with Output lt gt resolution when a `string` is req Pulumi Community #general

*Dealing with Output<> resolution when a `st...

great-sundown-78827

02/28/2024, 4:06 PM

Dealing with Output<> resolution when a
string
is required I get that we can pass
Output<X>
around and even pass it to an
foo: Input<string>
.. but what happen when we really need to resolve the output into a flat
string
? We’re trying to create a PagerDuty

Team

resource … but we want to have a boolean flag that when-true does a lookup of an existing team with that Name, and then passes the

team.id

field (resolved) into the

CustomResourceOptions.import

parameter, which is a string input. We tried something like this:

Copy code

export interface TeamArgs {
  readonly import?: boolean
}

export OurTeam extends CustomResource {
  constructor(name: string, args: TeamArgs, opts?: pulumi.ResourceOptions) {
    super('our:team', name, {}, opts);

    let existingTeamId: string | undefined = undefined
    if (args.import) {
      pagerduty.getTeamOutput({name: name}).id.apply((i) => existingTeamId = i)
    }
      
    this.team = new pagerduty.Team(
      name,
      { name: name, description: name, defaultRole: 'none' },
      { parent: this, import: args.existingTeamId },
    );
  }
}

The code seems to pass testing… and it runs… but it never really populates

existingTeamId.

Thoughts?

echoing-dinner-19531

02/28/2024, 5:12 PM

An output<string> might never resolve to a string, e.g. during preview a resource output can't be known. That's what output<T> tries to keep managed for you. It's kinda like a

Promise<T | undefined>

plus some extra tracking for secretness and accurate dependency tracking. As such there isn't really anything in the sdk to try and pull the inner value out of an output.

echoing-dinner-19531

02/28/2024, 5:13 PM

In this case, what your trying to do isn't really well supported by the engine but has a specific issue tracking it https://github.com/pulumi/pulumi/issues/3388

great-sundown-78827

02/28/2024, 5:41 PM

So I just spoke to one of our engineers who informed me that during the

pulumi preview

the code silently fails (doesn’t really execute) and therefore

existingTeamId = undefined

.. but when he runs

pulumi up

the call is executed. The thinking is that during the

preview

only existing vs desired state is computed … and none of the

get..()

calls actually run. Does this sound right?

little-cartoon-10569

02/28/2024, 6:48 PM

Pulumi doesn't promise to call the get methods during dry runs (previews). It explicitly says (can't remember where) that

apply()

calls won't be resolved during previews. In my experience, it seems to be smarter than that, and there are some calls to apply() that do get run. Maybe it depends on the provider or something. But yes, that's about right.

great-sundown-78827

02/28/2024, 7:16 PM

Ok, thanks

Open in Slack

Previous Next