Damn. GitHub is down 😅

Body, FetchError etc., but no function to invoke

re github: really, wow re the wizardry above: this clearly is beyond my limited Typescript foo - I kinda assumed fetch is simply part of my runtime environment -, but one learns a new thing every day 🙂

yes, that works!

thank you very much, @quiet-wolf-18467, once again!

now I got a very strange issue when I run pulumi up: preview passes, but for all the resources created via the dynamic provider I get

error: Program run without the Pulumi engine available; re-run using the `pulumi` CLI

background of that provider is: we're introducing a centralized configuration store that exposes, amongst other things, an API for tools that generate the values for certain configuration properties. pulumi is one of these tools and this provider is the intended bridge.

ignore the kubernetes issues

they are because I just started the migration from k8 secrets to that centralized config store

btw, I can also confirm that no API request ever arrived at said config store

other stuff gets executed normally, though. the snippet before was from diagnostics, here comes from Summary:

if it helps, I can screenshare, Teams or whatever

actually, after looking into the code, the issues with the k8 secret for rabbitmq is weird, too, because that secret is created by the helm chart, so not explicitly through my code - nothing has changed in that. I did another

pulumi up

run to exclude that this was a temporary issue. It was not. So it feels like the error in the dynamic provider that leads to said message about not being run from the pulumi CLI might create follow-up issues.

I'm now trying a run in which the `.send()`method of the provider has a

return

as its first line, to see if the errors go away then.

while it's still running, I see already that the resource creation of the dynamic resources now passes without error. the rabbitmq issue is still there, so that's my own fault, somehow, or maybe the helm chart has changed. UPDATE: no, that's gone, too, it just needed a bit to find the secret it had been creating itself. anyway, we know now for sure that the problem is triggered within the

.send()

method of the provider. UPDATE: the rabbitmq issue having gone away means that whatever this error with the `.send()`method, it leads to other issues, too.

so, meanwhile I narrowed it down to the actual fetch call. I replaced this with axios, same result. as long as neither fetch nor axios is being called, there is no error. tomorrow I will try to use low-level httprequests if I find how to do that in TS. in any case, any assistance/advise you might have, would be very much appreciated.

@quiet-wolf-18467 Yes, I'd like to very much, if you got the time

okay, I have further narrowed it down, it seems it has to do with creating the payload for the post request. I guess it will be some sort of null-reference I'm digging further...

one cannot call `pulumi.getStack()`inside the provider

if I replace that with a constant, it works

so, that's easy to work-around, I'll just pass it in as a parameter.

BUT it would be very nice if short-term you mentioned this in your docs for creating dynamic providers, prominently, and mid-term the error message would explain it.

another question related to dynamic providers: is it normal that when doing the preview, for updates, for diff it shows a serialized version of the whole provider? I kinda would prefer if it showed either nothing at all or, better, if I somehow could tell it what to display?

I think the

getStack()

thing makes sense, because providers aren’t stack aware, as the Pulumi program calls them over gRPC (Though dynamic providers are different, I believe the constraint is the same)

I’ll pass it on!

and thank you, for everything. I can say you guys rock in the support department! ❤️