We've had failing (due to timeout) unit tests for a little while. Looking into it now, I've tracked it down to

@pulumi/pulumi

3.202.0 -- when I switch to 3.201.0 the tests run fine, and they time out when using 3.202.0, repeatably. Most tests work; I haven't yet tracked down exactly what's different about the 24 that fail versus the 152 that pass. My console logging (in setMocks'

newResource()

) shows that in 3.201.0, all the expect resources are created in `before()`; in 3.202.0, only the top component resource is created, and none of the resources created in their constructors ever get as far as

newResource()

. When dumping the errors, Pulumi is reporting thousands of promises leaked. But I don't read much into that; whenever there's a timeout failure causing a test abort, I see that.

Feel free to ping me whenever 🙂 I just pick them up in the morning, I won't get woken up by it. Whats your top resource look like? Most importantly what does it pass to the super constructor for the input args.

Hi! I've determined that all the failures do have a common thread: they're the ones that create our Vpc wrapper component resource as a test dependency (though not necessary in before/beforeAll, I've moved it into the test function while experimenting). The Vpc wrapper is old code, and adds onto awsx.ec2.Vpc, using its older interfaces, with promises rather than apply, to iterate through subnets to build NACLs, security groups and routes.

OK thanks that's a lot of information. Nothing stands out as an obvious culprit so I'll have to dig into this a bit.

Did this change result in args to a component resource automatically getting stored in the resource? I'm seeing a pile of unexpected updates for my component resources, adding values that are used in the constructor but don't need to be stored.

If you need to opt-out you can just change the super call to ComponentConstructor to not pass those args.

but Pulumi is wanting to save them into state in plain text because they're in an arg. This isn't ideal.

That's unexpected. Secrets should still be propagating through args.

That's a big enough change that it deserved a big red warning label, I'm afraid.

Yeh seems its mostly gone unnoticed but has bitten a couple of users badly. Our internal testing had gone fine with only thing causing issues was circular references but we recommend against those anyway.

I'm seeing a pile of unexpected updates for my component

This is actually one of the big wins here, is now the engine can tell that a component is "updated" and so call lifecycle hooks for it.

If you need to opt-out you can just change the super call to ComponentConstructor to not pass those args.

This is good to know. This may be the quick way to get deployments happening again, then we can fix the couple of poor dev choices we made years ago afterwards.

Secrets should still be propagating through args.

They are. The code that alarmed me involved passing a plaintext secret into a constructor, which then wrapped it in a secret and put it in a property. The plaintext secret wasn't being put into state previously.

> I'm seeing a pile of unexpected updates for my component

This is actually one of the big wins here, is now the engine can tell that a component is "updated" and so call lifecycle hooks for it.

Good stuff. We don't have any of those, but good to know it'll work if we ever create any :)