This message was deleted.

Hmm - that doesn't sound right at all. Any details on exactly what you are trying to do?

pulumi preview

Huh - very odd - I can reproduce this as well. Will take a look to see what's causing this.

Thanks!

So - it turns out you can fix this by moving this line:

const client = new apigatewayv2();

From being outside of the

create

callback to being inside the

create

callback. It's a little involved why this makes such a big difference, but in short - dynamic providers take advantage of the same "function serialization" logic we use for turning callbacks into Lambdas (documented https://pulumi.io/reference/serializing-functions.html). To serialize the reference to the

client

defined outside of the callback, it looks like we effectively have to serialize a large part of the AWS SDK, and this takes a long time (as it's not really optimized for this). The experience here isn't ideal - it would be preferable to error instead of hang for so long for example. But the workaround should be simple.

Whoa! Crazy, but thanks for debugging it for me.

Yes - dynamic provider in current form is very low level - and missing many convenience safe gauards. That's part of why we haven't formally documented it yet. But it's super useful as a low level escape hatch. Lot's of work we want to do to make this simpler/safer for "normal" usage!

Yeah, I’m pretty interested in it, since a couple of services i’ve inherited lately have a sort of “plugin” concept that i’d like to make dynamic/stateful resources so that 5 teams aren’t all editing/deploying the same service that really shouldn’t have to care about the plugin implementations - it would be nice to expose a pulumi lib to consumers and they could deploy their plugins & dynamic resources seems like the perfect mechanism for that.