*Dealing with Output<> resolution when a `st...
# general
Dealing with Output<> resolution when a
is required
I get that we can pass
around and even pass it to an
foo: Input<string>
.. but what happen when we really need to resolve the output into a flat
We’re trying to create a PagerDuty
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
field (resolved) into the
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, description: name, defaultRole: 'none' },
      { parent: this, import: args.existingTeamId },
The code seems to pass testing… and it runs… but it never really populates
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
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
only existing vs desired state is computed … and none of the
calls actually run. Does this sound right?
Pulumi doesn't promise to call the get methods during dry runs (previews). It explicitly says (can't remember where) that
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.
Ok, thanks