How can I use fetch inside a dynamic provider? I g...
# typescript
a
How can I use fetch inside a dynamic provider? I get errors of the form:
Copy code
error: Error serializing '() => provider': index.js(28,47)

    '() => provider': index.js(28,47): captured
      variable 'provider' which indirectly referenced
        function 'Provider': configuration.ts(21,0): which referenced
          function 'send': configuration.ts(60,8): which could not be serialized because
            Unexpected missing variable in closure environment: fetch
q
I believe the best way to is use dynamic imports inside the function.
const fetch = await import(“node-fetch”)
a
okay, I didn't even know this was a thing o.O trying...
q
I’ll try and find an example
Damn. GitHub is down 😅
a
hmm. the problem I have now is: fetch then seems to be an object with members: • Blob
Body, FetchError etc., but no function to invoke
q
Ah. You’ll need import(“node-fetch”).default
a
ah, yes, that looks better. now I'll do the preview
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
Copy code
error: Program run without the Pulumi engine available; re-run using the `pulumi` CLI
q
I've not seen that before. Can you share more info? How are you running Pulumi, what's the dynamic provider look like?
a
sure. I run pulumi up from the commandline, quite normally. the provider looks like this:
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.
q
I'm really confused. If it's safe to do so, can you share full output from Pulumi up please?
a
console output is not so helpful, but the diagnostics in app.pulumi show more:
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.
q
@ancient-eve-13947 apologies, I was on a stream and then it was finishing time. Ping me if you wanna pair on this today
a
hey there
@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...
q
I'll be in office in about 30
a
ha! I found it
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?
q
Good debugging, @ancient-eve-13947_!
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)
a
it's also really no issue, as one can just pass it in. but, as I said, it would be nice if the error message was more clear 🙂
q
Definitely room for improvement 😄
I’ll pass it on!
a
thx
q
If I can help with anything else, feel free to reach out; though it seems like you’ve got a great handle on this 👍
a
regarding the thing with the diff display: is that a known limitation or an indication I'm doing something wrong or is there a way to overcome it?
q
No, I believe the entire provider is serialized and shown as a diff. I’ll check if that can be changed, but I believe that’s enforced atm
a
okay, if you find it's not, please let me know
💯 1
and thank you, for everything. I can say you guys rock in the support department! ❤️
🙌 1