https://pulumi.com logo
#general
Title
# general
g

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?
e

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.
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
g

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?
l

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.
g

great-sundown-78827

02/28/2024, 7:16 PM
Ok, thanks