https://pulumi.com
Join Slack
This message was deleted.
# golang
s
This message was deleted.
😞 2
a
Hey @brash-gigabyte-81569. I’m sorry to hear that. Just so I understand, your saying that: • You have written a component provider in go (using the 
pulumi-go-provider
framework) • You can successfully consume the provider you wrote in Pulumi YAML. • You cannot consume the provider you wrote in typescript because you get an unmarshalling error. Does that sound right? I’d love to see a repro of this, since everything you described should be possible.
b
that is correct
i am trying to build out a simple example but have been short on time lately ,once i get it done i can put the links here
related note, when i dump the variable the string is an urn
Let me know if you want to test anything
@ancient-policeman-24615 I am wondering if these changes that you are working on are related and if so if you would like me to test it out or anything.
a
Those changes are largely unrelated. Sorry for the extremely large response time. Last week was a hack week for us, and then I was on PTO. I’ll take a look at your example this week.
They do work in a similar area to where I think you are getting the area from, so they might turn out to be tangentially related.
b
Yeah, that’s why I was curious ha. Anyway, thanks for taking a look, hopefully I am just doing something wrong that is an easy change.
I figured it out and it is quite a nuanced bug. Issue presents itself when I have Provider A returning a reference to a Provider B resource but the main stack doesn’t use any Provider B’s resources directly in the main stack, only through Provider A. For example, if I have a provider that returns an s3 bucket, and then pass that s3 bucket into another component in Provider A it will fail as the aws provider wasn’t registered in the main stack so it treats the urn as a string instead of rehydrating the reference. However, if I create some aws resource in the main stack it will work. I have a feeling there is some initialization code that sets up resource tracking for a provider that doesn’t happen when I don’t directly use it within the main stack.
a
That is some excellent sleuthing. Each generated SDK has a 
RegisterResource
block: https://github.com/pulumi/pulumi-cloudflare/blob/cf179f8ec0138d1b2712d979f854a0e317ce826e/sdk/go/cloudflare/hostnameTlsSetting.go#L317-L325. That is the only thing I can think of that involves global initialization for deserialization.
b
This code here made me think that the provider list was being provided from the main stack https://github.com/pulumi/pulumi/blob/master/sdk/nodejs/provider/server.ts#L319
Which has now lead me to how imports behave on TS. Looks like I can define my import as 
import "@pulumi/aws";
instead of 
import * as aws from "@pulumi/aws";
on the main stack and it will ensure that the provider is added without needing to create an aws resource directly
a
I opened https://github.com/pulumi/pulumi-go-provider/issues/157 to track this. I think this is an error in code generation. I’ll put it in front of the people who would know right now.
👍 1
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by