This message was deleted.
# typescript
s
This message was deleted.
m
I think that I can answer this, though the answer for the
endpoint
bit isn’t particularly satisfying.
The constructor for the
pulumi.Resource
superclass needs to see all potential properties in the
props
bag, not just input properties. If the names of the output properties are not present in that bag, the
Resource
machinery can’t determine which output properties to expect.
So I think that if you change your code to this, things should work as you expect:
Copy code
class Cluster extends pulumi.dynamic.Resource {
    public readonly endpoint!: pulumi.Output<string>;

    constructor(
        name: string,
        props: IClusterInputs,
        opts?: pulumi.CustomResourceOptions,
    ) {
        super(new ClusterProvider(), name, { endpoint: undefined, ...props }, opts);
    }
}
The reason
pulumi.output(cluster.endpoint)
changed things is that it turned an
undefined
value into a resolved (but defined!)
pulumi.Output
value whose inner value is
undefined
.
w.r.t. `id`: you didn’t have to do anything special there because
id
is always defined by the SDK.
r
Oh, yeah I think you're right. Why do we have to "initialize"
endpoint
like that in the dynamic resource constructor?
m
I think that it’s because without that initialization, it’s not possible for the constructor to know what the set of output properties is for the resource. IIRC there are problems with attempting to iterate over the properties defined on
this
(e.g. properties that are present on every object shouldn’t be considered output properties), but my JS/TS expertise may be failing me here (cc @microscopic-pilot-97530).
r
Got it, that makes sense. Thanks.