https://github.com/pulumi/pulumi/blob/master/pkg/testing/pulumi-test-language/tests/testdata/l1-stack-reference/main.pp - if implementation does not handle this SigKey in test it will pass anyway -

secret

instead of being interpreted as JSON value String it's a JSON value map with SigKey - and it's interpreted as

secret

on output side by accident. If that the case I'll try to modify the test to include

toJSON

call to ensure that the SigKey is interpreted.

Oh we should enhance that test. It should check secrets work, but they do come via a separate field "secretOutputNames" not via the SigKey system

That's very weird, because I do not use secretOutputNames, but the test passes

ah yeh I think it might be that, looks like the engine will send back both sigkey style if accept_secrets is set, and the list of names. A lot of the other SDKs lift all secret values up to the top level property so if they had accept_secrets for stack references they end up seeing all of

outputs

as secret. Thus why we have the getOutput functions to strip the secret bit and reset it from the names list

So I guess it's the only place where sigkey is in nested key? I will have to research it more then.

I think they can turn up anywhere, we should probably add some conformance tests for that

That complicates a lot of things for me, but good to know. 👍