No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

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 <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map|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.

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>

<@U02J3T6A8LB> Since I made this work I discovered that `awsnative.ecs.TaskDefinition` unmasks secret outputs in the state under some conditions. Shall this be considered a bug?


 I do not have a problem with that mainly the opposite - when `containerDefinitions` aray contains a secret value, the entire array is encrypted and the ability get useful diff is gone.

I mean that the entire array of objects is considered a secret and masked, instead of a single value inside nested object eg. `[{k: secretValue}, {k: publicValue}]`

&gt; unmasks secret outputs in the state under some conditions. Shall this be considered a bug?
Unmasking is probably a bug

&gt; 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&lt;T[]&gt;` instead of `Output&lt;Output&lt;T&gt;[]&gt;`, 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&lt;Output&lt;T&gt;[]&gt;` to get the diff, right?