mirror of https://github.com/pulumi/pulumi.git
1da0555b6a
*Components* provide a means for Pulumi users to logically group and abstract sets of resources. While authors of Pulumi programs can define "local" components using e.g. the `ComponentResource` class of the NodeJS or Python SDK, these can only be consumed by programs written in the same language. Components implemented by provider `Construct` implementations, however (often called "remote" components), can be consumed by any appropriate client SDK, just like any other Pulumi resource. Despite their implementation involving gRPC protocol communications, remote components offer many of the same features as local components. For instance, just as it is possible for a local component's outputs to contain references to its child resources, so may a remote component return references to resources instantiated in its `Construct` implementation. On the wire, these are serialized using resource URNs and IDs. These values are then "hydrated" into fully fledged resource values by the calling client SDK. Hydration is powered by the `pulumi:pulumi:getResource` function. This is an invoke offered by the so-called *built-in* provider, alongside other core Pulumi concerns such as stack references. Under the hood, `getResource` is implemented by looking up URNs in a table of resources being managed by the executing program, and returning the appropriate state to the caller. Presently, this lookup only takes into account resources managed by Pulumi (that is, *resource registrations*). It does not take into account *reads* such as those caused by e.g. a `.get` call in a NodeJS SDK. Consequently, if a `Construct` implementation performs a `.get` and returns a reference to the read resource as an output, later hydrations of that reference will fail. This is the cause of #17515. This change fixes this by augmenting the built-in provider with a map of read resources, which is updated as a deployment progresses just as the list of registered resources being used already is. When a lookup in the registrations map fails, the read map is tried, with an error being raised only if that also fails. A pair of lifecycle tests are added to verify that the behaviour works as intended. Fixes #17515 |
||
|---|---|---|
| .. | ||
| diff.stderr.txt | ||
| diff.stdout.txt | ||
| eventstream.json | ||
| progress.stderr.txt | ||
| progress.stdout.txt | ||