Is it possible to have an Input like this?

interface ResourceArgs {
  [key: pulumi.Input<string>]: pulumi.Input<string>
}

because this is a problem:

[key: pulumi.Input<string>]

when the value is an

Output

I don't think so, object keys have to be plain strings afaik

hmm, I am trying to find some workaround for

ContainerDefinitions

from AWS ECS diffs because the classic provider supports only string which is complicated to read with multiple containers https://www.pulumi.com/registry/packages/aws/api-docs/ecs/taskdefinition/#containerdefinitions_nodejs And

awsnative

cannot be used because they consider an array of container definitions as unordered which makes

pulumi diffs

useless if you add/remove an item from the array and index changes https://www.pulumi.com/registry/packages/aws/api-docs/ecs/taskdefinition/#containerdefinitions_nodejs So my idea was to build a Dynamic provider just to store the values in the state file to give me nice diffs. And to avoid problem with array diffs, I though I could use the

name

property from container definition and create an Output object, which I partially succeeded but then I realized that it will only work as long as the

name

is a string, not an Input. Any tips on what I could do instead? I wanted to avoid stack outputs because they just flood the CLI with a wall of text

Wonder if a Map would work here? That might work ok with Output keys and if it doesn't sounds reasonable for us to see about making it work.

can you post a bit of your code?

In the end, I and my colleague made it work by black magic and quite possibly bending something in pulumi dynamic provider https://gist.github.com/1oglop1/5719c1fd11760472efe2b6af76bcec0b

unmasks secret outputs in the state under some conditions. Shall this be considered a bug?

Unmasking is probably a bug

I mean that the entire array of objects is considered a secret and masked, instead of a single value inside nested object

Urgh yeh it's the awkwardness of returning

Output<T[]>

instead of

Output<Output<T>[]>

, generally collapsing the layers of outputs down so you only have to deal with one layer is easier, but it means if there's a secret any where in the response the whole thing gets marked secret. Might be possible for engine state to keep track of it for each layer, but soon as it hits your program the value will get flattened.

Thanks, that means I will need to find a way to make make use of

Output<Output<T>[]>

to get the diff, right?