12494: [sdk/go] Track rehydrated components as dependencies r=justinvp a=justinvp
When expanding dependencies, local component resources act as aggregations of their descendants; rather than adding the component resource itself, each child resource is added as a dependency. Remote component resources, on the other hand, are added directly to the set, as they naturally act as aggregations of their children with respect to dependencies: the construction of a remote component always waits on the construction of its children.
46ccb5a22c/sdk/go/pulumi/rpc.go (L65-L91)
However, rehydrated components (i.e. instances of a component resource that have been recreated from a URN, typically via deserialization of a resource reference) aren't marked as a remote component and won't have any children from the SDK's perspective. And because of that, when their outputs are used, there won't be any dependencies kept for those outputs.
This change fixes rehydrated components to be marked as remote components, in the same way as "dependency resources" are marked as remote components, so that they are kept as a dependency.
This addresses cases where a component resource method is implemented in Go and the method returns results derived from the component's outputs. Inside the implementation of the provider's `Call`, the implementation will get a rehydrated instance of the component. Without this fix, the dependency on that component will not be kept in the returned output.
Here's a concrete example:
5d3372b4ae/tests/integration/construct_component_methods/testcomponent-go/main.go (L64-L68)
The above is a method implemented in a component provider. The `c *Component` receiver will be a rehydrated instance of the component. The method uses `pulumi.Sprintf` to create a result that combines some of the component's outputs. But the combined output that is returned won't have the dependency on the component kept, since the rehydrated component is a component and doesn't have any children. With the fix, the dependency will be kept and serialized as expected.
Part of #12471
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
20ee7fc734